Synchronous RX-TX Interface development

Discussions related to embedded firmware, driver, and user mode application software development
Post Reply
kartar
Posts: 19
Joined: Wed May 14, 2014 5:01 am

Synchronous RX-TX Interface development

Post by kartar »

Hi,
I am working on a radar project. The algorithm is based on the "Signal time of travel" which makes enormous requirements to the synchronization of the TX and RX threads. What I need to do, is to be able to start transmitting and receiving exactly simultanously or at least to get to know the delay that occured in between.

Any proposals how to do that? The best thing for my purpose would be a function like bladerf_stream(rx_stream, tx_stream). Or a function that starts the processing in the FPGA after the bladerf_stream function is called.

Thank you for any proposals
bpadalino
Posts: 303
Joined: Mon Mar 04, 2013 4:53 pm

Re: Synchronous RX-TX Interface development

Post by bpadalino »

There are some preliminary hooks in place in the FPGA in master to be able to handle timestamps.

These timestamps are based on the samplerate of the RX and TX clocks. Note that these clocks are 2x the normal sampling clock since it takes 2 clocks to get the (I,Q) baseband pair out of the LMS.

Currently there needs to be knowledge of how big the USB transfers are and putting the timestamp at the right point in the packet, or reading it out at the right time in the stream to understand what time the sample has.

If you don't mind a little programming, take a gander at the transceiver in YateBTS. I recommend setting the samplerates, then enabling the metadata flag on the NIOS GPIO - this should make the timestamps increase at the same clock rate and from 0. Then you should be able to push samples in and pull samples out all while knowing the structure of the underlying packet and how many samples are between timestamps. If you think you'd like to add this to the synchronous interface, please let us know and we can get the paperwork in place and discuss the development. It would be an awesome addition.

If you do mind a little programming, then we have the sync interface with metadata attached to it. It's meant to be able to say "Transmit this at this time", or "Give me the sample received at this time forward", but it isn't quite ready yet.

Let me know if this makes sense. I know it isn't as friendly as you would have hoped, but it's possible. Curiously, are you planning on using multiple devices to receive or transmit at the same time? There is a pull request at github that does that, but it's based off an old master and we feel a little uncomfortable pulling it in since we don't have a legal agreement in place.

Anyway, I hope you get a good direction. Let me know if you want more clarification.

Brian
kartar
Posts: 19
Joined: Wed May 14, 2014 5:01 am

Re: Synchronous RX-TX Interface development

Post by kartar »

Hi,
thank you for your proposals. Using just one device should be fine for me.

I took a look at the YateBTS Code as you proposed. Is it some kind of secreat behaviour in the library? Or is there any documentation that explains the meaning of the of the parameters?
To be honest, I hoped in a simple solution. I will have a look to the code, but in the moment, I don't see any other solution to go around the timestamps... :(
kartar
Posts: 19
Joined: Wed May 14, 2014 5:01 am

Re: Synchronous RX-TX Interface development

Post by kartar »

Hi,
I really appreciate your help and I think the timestamps can do what I need.

I looked into different sources and I am confused a little bit. According to the YateBTS and the FPGA code the documentation I found under https://github.com/Nuand/bladeRF/wiki/P ... ata-format must be outdated. I think the position of the parameters has been changed. More over, is the device packet length 1024 samples (Doc) or 512 samples (YateBTS Code)? Propably it is a good idea to write this value into the libbladerf.h file, if it change in the future and add the info how to enable metadata to the doc.

I looked into the FPGA code and is it true, that RX has the same timestamp as the TX? (bladerf-hosted.vhd line 897 rx_timestamp <= tx_timestamp; ). It is cool for me, but some kind of weard isn't it?
I would like to try to work with timestamps first, just to see how it really works. The tricky part I see using it in the TX path, is the need of a timestamp delay to make sure, the samples are in FPGA at time. But implementation in the sync interface is not a wrong idea at all... I will take look at it..

Thank you..
kartar
Posts: 19
Joined: Wed May 14, 2014 5:01 am

Re: Synchronous RX-TX Interface development

Post by kartar »

I will answer my questions by myself. For other who is interested in timestamps.
The RX timestamp is derived from the TX timestamp but only in the newer HDL code that precompiled in the moment. The packet size in my case is 256*sizeof(int32) (maybe a bug, I will explain it later). The first 4*int32 data in the packet is metadata and the offset of the timestamp in the metadata is 4 Bytes.

To use timestamps I compiled the latest FX3, HDL and Host code from egit. But I noticed following issues:
1. Sometimes the Timestamps(Packets) have an offset of 128. This means that the meta position in RX stream is not 0, 256, 512... but 128,384,510....
kartar
Posts: 19
Joined: Wed May 14, 2014 5:01 am

Re: Synchronous RX-TX Interface development

Post by kartar »

Ok,
I made the workaround to be able to catch the metadata moved by 128 samples in the RX stream and the RX Path works for me now. But I got stuck in the TX path :?

Sometimes, the TX thread works fine, but sometimes, only the num_xfers buffers will be transmitted and the thread ends in the timeout. It seems, like there is the same bug in the TX path as well, but I have no idea in the moment, how to make an workaround to this :-(

What I'm doing in the moment is that I read the timestamp from the device and put the timestamp + offset in the metadata field in the TX stream. The timestamp will be increased each TX packet. The RX Path can determine the offset between TX and RX.

Any suggestions? Is there any chance to fix the bug in the RX path? Maybe is the same issue in the TX Path as well. I looked into hdl code, but it is definitely all others than easy to read and understand.

Thanks
kartar
Posts: 19
Joined: Wed May 14, 2014 5:01 am

Re: Synchronous RX-TX Interface development

Post by kartar »

Hi,
I made more progress. Now The TX samples will be transmitted properly. But there is still issue in the sync. If I say TX samples at this time and RX samples at this time, there is still a time difference between the RX and TX. This can bee seen, if I set the first x samples to zero, the others to non-zero. The possible reasons that I can imagine is, that the TX or RX path have some old buffers inside, that moves timestamps or that the TX timestamps doesn't work properly.

I am curious, but have you tested the TX timestamps somehow? Especially with respect to the RX samples... Some kind of small test programm to verify the function...
kartar
Posts: 19
Joined: Wed May 14, 2014 5:01 am

Re: Synchronous RX-TX Interface development

Post by kartar »

It's alive :-)
After days and days of trying and frustration, I was able to create a working code, where the RX and TX is synchronized using timestamps. The behaviour changed, as the new updated from nuand came out and made the work extremely complicated. I switched back to sync interface, where I found the solution.

Using the sync interface and the latest image (june 21) from nuand site I have to call bladerf_close and bladerf_open between each transmission.. If you don't do that, the RX and TX path are no more synchronised (the tx data are moving in the RX samples - even using timestamp synchronisation). The good information is, this call has no impact to the device settings like frequency, bandwidth,..

I think, the whole reason for this behaviour is, that the library or hdl contains old packets and the next call causes that the data_fifo and meta_fifo are out of sync. I would recommend to introduce a fifo reset if the module is disabled.This could avoid old samples and strange behaviour at all...

Have fun....
bpadalino
Posts: 303
Joined: Mon Mar 04, 2013 4:53 pm

Re: Synchronous RX-TX Interface development

Post by bpadalino »

Thanks for the investigation work and the detailed reporting. We'll be sure to check out this behavior and fix it.

You shouldn't have to open and close the device to get rid of any stale samples, but that hint is huge in debugging! Thanks very much!
kartar
Posts: 19
Joined: Wed May 14, 2014 5:01 am

Re: Synchronous RX-TX Interface development

Post by kartar »

Hi,
My sync interface is working quite acceptable in the moment, but I have still one issue I can't find a solution for. I try to ask here if someone can find a solution..
I can't find a way how to sync the rx and tx dac in the lms. The problem is the double sampling rate on the lms input. The TX part is controled by IQ select, which determine the half clock rising edge of the DAC. But in the rx, the dac rising edge is not always the same as in tx which cause the rx offset of 1/(2*sampling rate).

I already tried to sync lms_rx_enable output to half rx_clock, but without any result....

Any idea how to reach the full sync?
bpssoft
Posts: 1
Joined: Tue Nov 11, 2014 2:03 am

Re: Synchronous RX-TX Interface development

Post by bpssoft »

Is it possible to share your current synchronisation code?
I'm very intrested in RX-TX synchronisation
bpadalino
Posts: 303
Joined: Mon Mar 04, 2013 4:53 pm

Re: Synchronous RX-TX Interface development

Post by bpadalino »

Give the current master code a try and be sure to set the appropriate samplerates before configuring the synchronous sample stream.

Also note that you want the META sampletype.

Check the samples in the documentation.

Brian
yaya
Posts: 1
Joined: Thu Nov 17, 2016 9:23 pm

Re: Synchronous RX-TX Interface development

Post by yaya »

Hi,
I'm new to the BladeRF. But, working on an FMCW radar and need the right delay between RX and TX. Is this achievable now - Synchronous RX-TX? If yes, appreciate if anybody can share the method. I'm running using simulink and getting random rx time even in loopback mode.
Vic
Posts: 1
Joined: Wed Dec 16, 2015 11:30 am

Re: Synchronous RX-TX Interface development

Post by Vic »

Dear all,

I found this topic very interesting. I tried to follow the timestamp issue but I hit a wall. Mostly based of my lack of expertise in this matter. Attached is a GNURadio block diagram I made. All works well with the exception of TX/Rx sync. Anybody have a hint for it? Thanks in advance.
Image/Users/vjarao/Desktop/Screen Shot 2020-03-16 at 6.43.11 PM.png
Post Reply