73 Laurent F4FDW
cut the 5V track to pin 5 on the board, grounded pin 5 and 6, cut the track supplying pin3 with 3v3 (probably not necessary to do).
put a 150K resistor in parallel with R5 (to set the supply voltage to 1.2V) and changed the name in flash memory of the FTDI chip to
The inspiration was from Brian G4EWJ who posted a picture of a Minitiouner 1.0 being used as a Knucker.
A bit of upcycling!
Express TX at 150khz and above.
RX on knucker Portsdown4
All working. Also tested BBC1 broadcast DVB-T at 8000khz and that works well on the Portsdown 7" display.
Had a contact with M0DTS a few days ago on DVB-T 16Qam 500 and 1000khz
Last night ran some tests with M0DTS on 437.5Mhz
Pluto TX c920 and Portsdown4 RX no preamp and 1mhz wide filter 9element Tonna
The 26KM link was on the edge at 50mw and 1000khz
Lowest we could decode was 150khz. which was reliable (140khz 125khz wouldn't go)
Once the bandwidth was below 500khz the SNR dropped and the power levels had to be increased to maintain the link.
Loss of signal to re-displaying a signal is around 10 seconds at the lower khz bandwidths.
I've only found it around 513.800MHz so far and it may be insignificant on an 8MHz wide channel but it may be more of an issue on the narrower bandwidths used for DATV if the same problem occurs in an amateur band.
Enter 513.82MHz and the green highlighted frequency shows 513.82
Enter 513.810MHz and it shows 513.809
Edit the key again and it has retained 513.809
Enter 513.800MHz and it shows 513.799
Enter 513.790MHz and it shows 513.789
Enter 513.780MHz and it shows 513.78
It won't surprise you to hear that this is a "float to integer to float" rounding error involved in the conversion between MHz and kHz and back. I've put a small bias in there now to try to make sure that it always falls the right way. It'll be in the next update.
Thanks for reporting this.
Well done for getting the build complete - surprised about Digikey, normally very fast.
We have noted that the system does not currently perform reliably below 250KHz so suggest you focus testing above that bandwidth.
Re DVB-T parameters, the first point to note is that we directly refer to the bandwidth and not symbol rate, which in DVB-S has an impact on bandwidth. And of course, the narrower the bandwidth, the better s/n ratio so it should go further....
There are 2 other parameters:
FEC performs the same function as FEC in DVB-S but changing it in DVB-T only affects the error correction and payload bits (hence picture quality) and not bandwidth as it does in DVB-S.
Guard interval is specifically related to multipath protection and nothing else and does again affect the payload bit rate - hence when we did tests on QO100 we set this to 1/32 as there is no multipath on the satellite link.
Charles may have some input on what parameters to set for what path but I suspect we don't really know what to expect, particularly on the lower VHF and HF bands - we suspect for 70cms mobile we will need heavy guard interval protection but of course we can't try that until the lockdown is relaxed
Hope this helps
I have no recomendations, personally I prefer to use wider bandwidths, lower order constellations and heavier FEC rather high order constellations
and very narrow bandwidths.
In a mobile environment multipath from buildings is around 5us I believe, short and sharp, again wide bandwidths allow for Doppler spreading as
the carriers are futher apart and the extra FEC allows for the deep spectral nulls.