Forums

The Anything Transmitter - progress report.....

Started by Jan Panteltje April 21, 2013
Minority report?
 http://www.panteltje.com/pub/anything_transmitter_fifo_test_wiring_side_IMG_3837.GIF

Things work out great.
As mentioned in previous postings, the idea is to send IQ data (for example recorded with RTL_SDR)
from a Raspberry Pi SDcard to a dual DAC AD9761 into a AD8346 quadrature modulator.

                   8kB FIFO
Raspberry Pi -> CY7C433-25PC_FIFO -> AD9761_DAC -> AD8346_QAM_MODULATOR -> RF out 
                |                        ^             ^
             <--                         |             |
             handshake                 read clock    RF oscillator
                                        bitrate

After some software experiments I can send 4096000 bytes per second from the Raspberry into the FIFO.
 http://panteltje.com/pub/send_iq.c

This is a critical minimum required for for example a GPS replay attack using GPS recordings made with a
RTL_SDR DVB-T stick as described in a previous posts in this group.

Lots of tricks were used, I use fread() in the full Linux buffer (8 kB default) to reduce systems calls,
use the 8 bit data and 1 bit makes 9 bits, the ninth bit is the I/!Q flag,
it tells the hardware if the byte is an I or Q value.

In the end I had some time left, allowing me to send a separate pulse from the Raspberry to load the FIFO!
Less hardware required.

There is a simple handshake, the Raspberry only clocks new values into the FIFO if that is not full.
As now the supply of bytes is always faster than the read out speed, there is no need to check for FIFO empty..
the 2 extra diodes in the picture can go.
 http://panteltje.com/pub/anything_transmitter_fifo_test_component_side_IMG_3838.GIF

These FIFO chips are very interesting things, and hard to understand,
you need to put data lines in parallel to make them work in depth expansion...

That gave me the idea of simply putting those on top of each other:
 http://panteltje.com/pub/fifo_depth_expansion_IMG_3839.GIF

as that requires less wires and makes adding more FIFOs easy, needs one more diode per 4 k FIFO.

And yes, I still use diode OR gates..... [1]
:-)

As it looks now, with 8 bytes IQ data at 4096 MB/s (2048 Msamples / per second),
and these AD9761 DACs, 64 QAM modulation should be no problem at that speed.
So far I have tested the FIFO working, next is the data lines to that DAC, then the I/!I and Q/!Q lines to the AD8346.
The VCO has already been tested of board....

And my dear readers, this is also the door to a high quality DVB-T (digital TV) transmitter,
Actually DVB-T is QAM 64 where I live....
This is better then the 4  or 2 bits (QAM 4?) that I have seen from amateur digital TV?
And of course the bitrates for TeeVee (digital) are very very much lower that used here ....
Maybe I will solder in a 74HCT4046 as bitrate clock oscillator, as it can be PLLed too,
not sure about the accuracy needed, there is, if needed, a FPGA board (other connector in picture)
with Rubidium reference that can provide any clocks I need.
But the RTL_SDR stick it's own sample speed accuracy, is it set by the PC or by the xtal in that USB stick?
Will have to look it up.
And what will be the effect of small changes in the sample clock on GPS?
I just feel like a multi game chess player, so many projects all evolving at the same time.
For the electronics enthusiast a great source of learning and gaining experience.
 
[1] If I need more FIFO because of for example the Linux task switch interrupt,
then I can use some very fast microwave diodes with low capacitance for up to hundreds of chips...
that many input fast OR gates are hard to find anyways,
and this does level conversion too, all logic here is 5V, and the Raspberry is 3.3 V logic and not 5 V tolerant on its inputs.


Copyright Jan Panteltje 2013-always All Right Reserved
Jan Panteltje <pNaonStpealmtje@yahoo.com> writes:

> Lots of tricks were used, I use fread() in the full Linux buffer (8 kB default) to reduce systems calls, > use the 8 bit data and 1 bit makes 9 bits, the ninth bit is the I/!Q flag, > it tells the hardware if the byte is an I or Q value.
If you can keep up the data flowing without breaks, you won't need any I/Q flags - just have the channels alternating IQIQIQIQ. You can't really tell whether the sequence starts with I or Q, but at most you'll have a constant 90deg phase shift, which really does not matter unless you're targeting carrier sync with some other part. I still remember when I got the first samples for AD9857 and was trying to find out a way to tell AD9857 which sample is I and which is Q and then having the lamp light up! -- Mikko OH2HVJ
On a sunny day (Wed, 24 Apr 2013 09:01:59 +0300) it happened mikko
<my_callsign@sral.fi> wrote in
<871ua0qxew.fsf@labserve1.i-did-not-set--mail-host-address--so-tickle-me>:

>Jan Panteltje <pNaonStpealmtje@yahoo.com> writes: > >> Lots of tricks were used, I use fread() in the full Linux buffer (8 kB default) to reduce systems calls, >> use the 8 bit data and 1 bit makes 9 bits, the ninth bit is the I/!Q flag, >> it tells the hardware if the byte is an I or Q value. > >If you can keep up the data flowing without breaks, you won't need any >I/Q flags - just have the channels alternating IQIQIQIQ.
Yes. I deduced that at some point from the datasheet 'state machine' story.
>You can't really tell whether the sequence starts with I or Q, but at most >you'll have a constant 90deg phase shift, which really does not matter >unless you're targeting carrier sync with some other part.
Absolutely true, but may get problematic once you have more than one of these working together in some way.
>I still remember when I got the first samples for AD9857 and was trying >to find out a way to tell AD9857 which sample is I and which is Q and >then having the lamp light up!
Na yaj, the bit is free, Raspberry has plenty of I/O pins, and the FIFO chips are 9 bits, so I just wired that to bit 9 and that to the 'select' input of the DAC. Already with testing, with the scope on the DAC output, I can tell it has I and Q the right way around :-) What I do not like about that dual DAC is that if I listen to these generated 'audio' tones, I can hear al sort of aliasing, scope shows it too. I think this is because of that internal multi stage filtering. Already I decided if that is going to give problems, I have 2 old video DACs as standby. Those are clean... Lot more experimenting to do... Thanks for the feedback.