-1

I'm working on a C program that transmits samples over USB3 for a set period of time (1-10 us), and then receives samples for 100-1000 us. I have a rudimentary pthread implementation where the TX and RX routines are each handled as a thread. The reason for this is that in order to test the actual TX routine, the RX needs to run and sample before the transmitter is activated.

Note that I have very little C experience outside of embedded applications and this is my first time dabbling with pthread.

My question is, since I know exactly how many samples I need to transmit and receive, how can I e.g. start the RX thread once the TX thread is done executing and vice versa? How can I ensure that the timing stays consistent? Sampling at 10 MHz causes some harsh timing requirements.

Thanks!

EDIT:

To provide a little more detail, my device is a bladeRF x40 SDR, and communication to the device is handled by a FX3 microcontroller, which occurs over a USB3 connection. I'm running Xubuntu 14.04. Processing, scheduling and configuration however is handled by a C program which runs on the PC.

user2742907
  • 87
  • 1
  • 11
  • On which operating system? Standard C99 does not know about USB3! – Basile Starynkevitch Sep 17 '14 at 07:14
  • 1
    If on Linux, why don't you use some multiplexing syscall like [poll(2)](http://man7.org/linux/man-pages/man2/poll.2.html)? – Basile Starynkevitch Sep 17 '14 at 07:18
  • I'm using a library to communicate to my device over USB3, and even though everything is compatible with Windows / OSX I'm running Xubuntu 14.04, should probably have mentioned that. – user2742907 Sep 17 '14 at 09:29
  • Can you not just keep the rx thread running all the time with a loop athat receives samples as and when they come in? Why do you have to start it continually? – Martin James Sep 17 '14 at 09:43
  • I can try that I suppose, but the basic functionality of my system (pulsed radar) dictates that I have very specific TX/RX times. Receiving while I'm not finished transmitting means that I'm receiving a whole bunch of samples that mean nothing, and working around that can get very tacky. – user2742907 Sep 17 '14 at 09:55
  • Also receiving a set amount of samples without considering when the TX routine is running is going to cause problems with synchronization, and the two streams have to be synchronized. – user2742907 Sep 17 '14 at 10:03
  • Hmm.. sounds like the protocol with the radar equipment is particularly poor:( If I assume there is no protocol at all, then you have a problem. Signaling the rx thread with a condvar to make it run, (say), is going to take a few us at least, and have some jitter. EM waves travel a long way in that time. |OK, then, why a tx and rx thread? Just use one thread. Send off the tx pulse data and then immediately start listening for rx data with some suitable 'rangeLimit' timer? Once the range limit has been reached, you can loop back and send another pulse. – Martin James Sep 17 '14 at 12:30
  • Thanks for the input. I could do that, if I start the RX right after the TX is done there is no need for a timer, I have a spec for a minimum range which is determined by the length of my TX pulse. I originally had separate threads in order to test the internal loopback mode. – user2742907 Sep 18 '14 at 07:31

2 Answers2

2

You don't say anything about your platform, except that it supports pthreads.

So, assuming Linux, you're going to have to realize that in general Linux is not a real-time operating system, and what you're doing sure sounds as if has real-time timing requirements.

There are real-time variants of Linux, I'm not sure how they'd suit your needs. You might also be able to achieve better performance by doing the work in a kernel driver, but then you won't have access to pthreads so you're going to have to be a bit more low-level.

unwind
  • 391,730
  • 64
  • 469
  • 606
  • Yes, apologies I should have mentioned my platform and it is indeed Linux. I would rather not dig into the kernel driver, as I've said in another comment I'm communicating to my device over USB3 using a manufacturer library. – user2742907 Sep 17 '14 at 09:31
0

Thought I'd post my solution.

While the next build of the bladeRF firmware and FPGA image will include the option to add metadata (timestamps) to the synchronous interface, until then there's no real way in which I can know at which time instants certain events occurred.

What I do know is my sampling rate, and exactly how many samples I need to transmit and receive at which times relative to each other. Therefore, by using conditional variables (with pthread), I can signal my receiver to start receiving samples at the desired instant. Since TX and RX operations happen in a very specific sequence, I can calculate delays by counting the number of samples and multiplying by the sampling rate, which has proven to be within 95-98% accurate.

This obviously means that since my TX and RX threads are running simultaneously, there are chunks of data within the received set of samples that will be useless, and I have another routine in place to discard those samples.

user2742907
  • 87
  • 1
  • 11