Proposing a new way to implement TX hardware

[lty1993]

I am proposing a new architecture for TX hardware.

Since the current design utilizing several dedicated TX silicons for supporting different protocols, it needs to keep adding more and more chips for supporting new protocols.

Instead, we can implement the TX using the SDR way.

AT86RF215IQ can be the right choice for RF transceiver IC. It is much cheaper than AD936X, and it is still a capable sub-1G and 2.4G narrow band IQ transceiver.

Then, we need a powerful IQ baseband processor — Xilinx XC7Z010 can be the right choice. Since we are only dealing with narrowband communication, an ARM Cortex-A should be sufficient for providing processing power. XC7Z010 has an additional advantage, which is to implement some DSP code into FPGA to accelerate the processing speed. However, XC7Z010 is quite small FPGA, and it is impossible to achieve the entire baseband processor onto its FPGA part.

If anyone interested in this design, I can start designing the hardware.

[pascallanger]

That would be awesome. I'm thinking it will be a lot to learn but that would enable us to do much more than today.

[lty1993]

The hardware architecture will be similar to the following paper: https://homes.cs.washington.edu/~gshyam/Papers/tinysdr.pdf

[pascallanger]

Some reading in perspective. Thanks!

[pascallanger]

Any news on your side?

[pascallanger]

Any progress?

[markran]

I think this sounds great. Unfortunately, I don't have the technical chops to help design it but I wanted to post to express my full and enthusiastic moral support!

[lty1993]

@pascallanger Still prototyping the design using dev boards. Once finished, I will move onto the PCB design.

[pascallanger]

@lty1993 I haven't heard anything from you since monthes. Any progress? I think we are all quite queen to get in this space and any help is appreciated.

[diego0815]

As the BW of the TX signal is not very high I suppose an FPGA might not be required, probably an arm m4 or m7 with reasonable clocks might do the trick.

But unfortunately in this field my strength is more admiring what clever people all can achieve rather than contributing myself...

[diego0815]

Just as a side note, to quickly start playing with SDR I guess at the moment pluto sdr is the most affordable solution covering our bands: https://www.passion-radio.fr/emetteur-sdr/pluto-sdr-788.html this is probably not the cheapest source but the quickest I found in my browsing history...

[lty1993]

As the BW of the TX signal is not very high I suppose an FPGA might not be required, probably an arm m4 or m7 with reasonable clocks might do the trick.

But unfortunately in this field my strength is more admiring what clever people all can achieve rather than contributing myself...

Usually, IQ transceiver IC requires LVDS to communicate with them, and the bandwidth requirement is quite high for such devices (128Mbps for AT86RF215IQ). I don't see any popular MCU or MPU has a general-purpose LVDS output buffer on it, So FPGA may be unavoidable.

Just as a side note, to quickly start playing with SDR I guess at the moment pluto sdr is the most affordable solution covering our bands: https://www.passion-radio.fr/emetteur-sdr/pluto-sdr-788.html this is probably not the cheapest source but the quickest I found in my browsing history...

PlutoSDR only output about 0db, you have to have an external PA and filter in order to make it work in the field. But it would be useful for reverse-engineering the wireless protocol.

[diego0815]

Usually, IQ transceiver IC requires LVDS to communicate with them, and the bandwidth requirement is quite high for such devices (128Mbps for AT86RF215IQ). I don't see any popular MCU or MPU has a general-purpose LVDS output buffer on it, So FPGA may be unavoidable.

Well that's it's design limit I'd suppose, for a 500kHz BW signal like i.e. Flysky you need two 500ksps DACs, one for I and Q respectively, or one single DAC w/ 1Msps, and for telemetry the same in reverse (ADC), the LVDS interface can for sure be solved with a different approach, but tbh I didn't dig that far into this matter yet.

PlutoSDR only output about 0db, you have to have an external PA and filter in order to make it work in the field. But it would be useful for reverse-engineering the wireless protocol.

That's the idea, once the reversing is done I wouldn't want to fly an SDR meant as a devel tool, but rather a custom designed module. But the pluto would allow separating HW and SW development.

[diego0815]

Ok forget my statement about ADC/DAC, as we are having them integrated in the I/Q frontend, else why LVDS, but still the data rates follow Shannon's law. Should the frontend mandate the 128Mbps transfer speed then that's more than weird.

Edit: just checked the full datasheet and am a bit puzzled on page 24 ff it states that it has a 128mbps interface (@4MHz), but then there is also a setting for the sample rate and this suggests you can go down to 400kHz, see also figure 6-1 and 6-6, as well as descriptions of Registers TXDFE.SR: TX Sample Rate and RXDFE.SR: RX Sample Rate .

There is an up/down sampler shown, which wouldn't be required if you would provide a fixed samplingrate of 4Msps.

But to draw a final conclusion I think one would have to dig much deeper into the matter, than what I did in the past couple of minutes. Probably even do some testing, or ask some questions to some people familiar with this very IC.

[OpenUAS]

While a super great idea IMHO, maybe close the issue? Partly if even the module would be created the pricepoint also would be way above current module price and likely not picked up en masse.