It will vary with temperature but it won't be anything to do with the pi or the SD card.
It is most likely to be due to the change in frequency of the crystals in the sound card and Pluto.
The sound card crystal determines the rate that samples are generated. The pluto crystal determines the rate that they are consumed. The GNU radio code maintains that relationship but only if the two crystals are accurate, which they never will be. If the sound card generates samples slightly too fast then the buffers will slowly increase in size.
It is a known problem with GNU radio when there is more than one frequency controlled block.
If it was possible to run the pluto and the sound card from the same reference crystal then the problem would go away.
Colin G4EML
Help PTT - 3 second to transmit
-
radiogareth
- Posts: 1236
- Joined: Wed Jan 06, 2016 9:46 am
Re: Help PTT - 3 second to transmit
Interesting 'interactions'....not sure what crystal is is used on the little USB soundcard dongle unless its under the COB pellet?
Wonder if something like a Progrock2 by QRPLabs could be either driven from the Pluto 40MHz and set to provide the required clock for the Soundcard or something. The Progrock2 is GPS lockable and would possibly provide reasonable stability certainly for the lower bands. I have used one to generate a 10MHz clock for an ADF4351 itself set to produce fundamental frequencies and 3 and 7th harmonics for 10 &24 GHz. At 24GHz there is a bit of warble.
Gareth
Wonder if something like a Progrock2 by QRPLabs could be either driven from the Pluto 40MHz and set to provide the required clock for the Soundcard or something. The Progrock2 is GPS lockable and would possibly provide reasonable stability certainly for the lower bands. I have used one to generate a 10MHz clock for an ADF4351 itself set to produce fundamental frequencies and 3 and 7th harmonics for 10 &24 GHz. At 24GHz there is a bit of warble.
Gareth
Re: Help PTT - 3 second to transmit
I am active on LF (136kHz) and one of the more esoteric long transmission duration modes called Ebnaut saw people locking their sound card to other parts of the transmission or reception chain for long term joint timing stability.
I think they used Trimble Thunderbolts or the small NEO boards.
Ebnaut was well outside my technical comfort zone, but was very interesting nonetheless.
Chris 2E0ILY
I think they used Trimble Thunderbolts or the small NEO boards.
Ebnaut was well outside my technical comfort zone, but was very interesting nonetheless.
Chris 2E0ILY
Re: Help PTT - 3 second to transmit
When I say 'crystal' in the sound card it could be any time reference such as a resonator or even an RC oscillator. The sound device generates samples at 48KHz, it is how accurate that 48KHz is that matters.
Internally Langstone works at a 48KHz sample rate most of the way through but has to convert that to 528KHz by interpolating by 11 to send to the Pluto. It is then up to the Pluto to consume the samples at exactly 528KHz. The Pluto sample rate is controlled by its own TCXO. If the sound card generates samples slightly too fast then the extra samples get stored in the buffers between the GNU radio blocks, increasing the delay. Likewise if the sound card generates samples too slowly the pluto runs out of data and the RF output starts to stutter.
It would be nice to be able to flush out these buffers before each transmission but there does not appear to be a way to do this in GNU radio. At least I have not found one that works.
Colin G4EML
Internally Langstone works at a 48KHz sample rate most of the way through but has to convert that to 528KHz by interpolating by 11 to send to the Pluto. It is then up to the Pluto to consume the samples at exactly 528KHz. The Pluto sample rate is controlled by its own TCXO. If the sound card generates samples slightly too fast then the extra samples get stored in the buffers between the GNU radio blocks, increasing the delay. Likewise if the sound card generates samples too slowly the pluto runs out of data and the RF output starts to stutter.
It would be nice to be able to flush out these buffers before each transmission but there does not appear to be a way to do this in GNU radio. At least I have not found one that works.
Colin G4EML