PLuto expansion to 50MHz??

[radiogareth]

I suspect a number of you have found/used the amazing SATSAGEM software for the Pluto, (http://www.albfer.com/satsagen-download-page/) which is worth owning a Pluto for alone.....
As it covers down to 50MHz I asked the question 'How was this done' and might it be applied to the DATV Pluto transmit/receive software.
Here is the answer...
"The VCO of TX can be tuned from 50MHz without any particular stratagem. I suppose that your program have the TX limit on 70MHz for the compliance of the technical specifications of Pluto only, probably related to the design of the TX line.
The VCO of RX can be tuned from 70MHz only (so the libiio says...), in this frangent SATSAGEN, in the range from 50MHz to 70MHz, not operate in swept-tuned but fix the VCO on 70MHz and analyze the LSB FFT results on maximum sampling frequency instead."

So superficially it would seem that its coverage could be extended maybe both in the AMSAT-DL DVBS2 receive software and the TX code by Evaraste and Charles (DVBEXpress).

Most definitely beyond me, but it would certianly improve the capabilities of the Puto in DVB-Land.

Gareth

[G4GUO]

I have not tried it with the Express software but looking at my code I set the lower TX frequency limit to 48 MHz so it might well work.

- Charles

[g0mjw]

That is interesting, though I am not sure how useful it is as there isn't much activity on 6m. Do you have any plans for an update to express? It's the only windows software I am aware of that supports express, lime and pluto but there are limitations that prevent it being as useful as it could be at very low SR. Very low SR, say 66k QPSK and 35ks 8 PSK are sufficient for a basic QSO rather than HDTV, but might make 6m DATV DX interesting.

Mike

[G4GUO]

Hi Mike,
I don't want to hijack this thread but the reason I have not released a new version of Express is simply that I have been unable
to get the AAC codec to work. Whenever I call it, it returns an internal floating point error. Other than that I have added NVIDIA
codec support (I was using the NVENC codec on the net last Thursday).

On another topic yesterday I came across NVIDIAs RTX Voice

https://www.nvidia.com/en-us/geforce/gu ... tup-guide/
I watched a couple of YouTube videos about it and it seems to work extremely well (kills off screaming kids, fan noise etc)
it requires an RTX card to work though. Something else to play with when I get the time.

- Charles

[g0mjw]

Hi Charles,

Interesting. Memory allocation problem perhaps. Could you maybe call ffmpeg's codec instead?

Mike

[G4GUO]

I am using FFmpeg codec (via the API), that is the problem.
It takes samples in floating point format (the MP1 codec uses 16 bit fixed format) also the sample frame sizes are different.
There is more than 1 AAC codec in FFmpeg. The configuration returns an OK it only fails when given a block of samples.
Google indicates that it is a known issue in the codec. It may have been fixed in a later version.

- C

[radiogareth]

I knew I'd be lost :-; but please feel free to hijack, this is the sort of discussion i expected/we need. Limited activity on 6 but more possible as more options pop up and we can run shed loads of power at good linearity.
Gareth

[G3VZV]

Surely we should be experimenting with (RB) DVB-T on 6 metres? This would help with the inevitable multi-pathing that occurs on this band under DX conditions..

[g0mjw]

I am using FFmpeg codec (via the API), that is the problem.
It takes samples in floating point format (the MP1 codec uses 16 bit fixed format) also the sample frame sizes are different.
There is more than 1 AAC codec in FFmpeg. The configuration returns an OK it only fails when given a block of samples.
Google indicates that it is a known issue in the codec. It may have been fixed in a later version.

- C

Oh - one of those problems... lots on stack exchange. Things about buffer sizes and warnings it's experimental. Google searching implies there has been a lot of development on the codec recently so it might have been fixed. Perhaps Opus would be better at 8ks though not supported by receivers. I am not even sure most receivers (e.g Octagon) support 8 kb/s AAC but that's immaterial as they don't support 66ks either.

Mike

[g0mjw]

Surely we should be experimenting with (RB) DVB-T on 6 metres? This would help with the inevitable multi-pathing that occurs on this band under DX conditions..

Well maybe but DVB-T would need to be scaled to fit. Maybe adapting the DRM standard might be more robust and there is code for it on github, maybe even the gnuradio GR-DRM code would be helpful. As always, my problem is there is nobody within terrestrial range to test these things, but with QO-100 perhaps we should be looking at doing that.