Official bladeRF forum

Hi,

I'm trying to figure out how the metadata works. As seen in the metadata.h :
https://github.com/Nuand/bladeRF/blob/m ... .h#L22-L76
the data from the FPGA to de FX3 is "packed" in messages, these containing a header and 2k -16 bytes of samples.

I'm interested in answering the following questions:
1 - Is the metadata used by the FX3? Is the data provided by the FX3 to the host modified in any way?
2 - Can I capture data with metadata? (using the bladeRF-cli interface or Osmocom? )
3 - I'm interested in using the metadata for my application: I noticed the flags are constant and I'm thinking in replacing them with other useful info for my application. Could this generate any problems?
4 -I found that in the TAMER block inside the FPGA the timestamps are generated but there is one timestamp for one message, I don't understand to which of the samples corresponds.


Thanks in advance.
Florencia

Hi Jon, thanks for your response.
I still have some doubts. Let me explain what we are thinking in doing so you have a better idea of where I'm aiming to. In my university there's an investigation group that has developed an ISDBT receiver in GNU Radio: https://github.com/git-artes/gr-isdbt. Our goal is to develop three blocks in the Blade's FPGA that are equivalent to the first three blocks in the ISDBT current project (they are part of what its's called the inner receiver) and make it transparent to the following blocks in GNU Radio.

These blocks are in charge of frequency and time correction and also in performing an FFT to the OFDM symbol. These means that the output of our system will have a delimited length (the length of an OFDM symbol) and it is crucial to the application to have a way of identifying them in the FPGA - USB - GNU Radio transmission.
Having these said, we want to add metadata to each message transferred from the FPGA to the host identifying in case there's a new symbol, where it starts. (Bear in mind that an OFDM Symbol is in this case in a worst scenario 8k which means you need 16 and .13 messages to transmit a complete symbol).

1) We need to receive metadata in the PC, by metadata I mean the 16 byte header of each message:

* +-----------------+
* 0x00 | Reserved | 4 bytes
* +-----------------+
* 0x04 | Timestamp | 8 bytes, Little-endian uint64_t
* +-----------------+
* 0x0c | Flags | 4 bytes, Little-endian uint32_t
* +-----------------+

In particular, the flags or the reserved bytes.

We have made some tests, modifying the OSMOCOM Source. We successfully received TIMESTAMPS but in the FLAGS' bytes instead of receiving x"12344321" as we expected, we received (x"000CFFFF").
In fifo_writer.vhd file the 78's line :
meta_fifo_data <= x"FFFFFFFF" & std_logic_vector(timestamp) & x"12344321";
If the metadata is not modified in the FX3 do you have any ideas why are we receiving something different in the FLAGS' bytes?

2) Assuming we could receive metadata not modified with the OSMOCOM Source Block, we are thinking in modifying the FLAGS x"12344321" or RESERVED Bytes x"FFFFFFFF" from the fifo_writer.vhd. Do you use any of these bytes?

3) We would also like to know if we could modify the timestamps i the FPGA. Is these information used in something else than the synchronisation?

Thanks a lot.
Florencia

Hi Jon, thank you for your response.
We have been working some more..

The modification in the OSMOCOM Source block was made in the bladerf_source_c.cc: With this modification we were able to receive metadata exactly as it was sent from the FPGA. The problem we were having before was on how to interpret the bytes received (as GnuRadio delivers the data in gr-complex).

Do you think there is a better way to receive metadata? A better alternative to the code provided before?
We tried setting the GPIO in the BladeRF-CLI but the bit that enables timestamps was erased as we saw when reading the GPIO status after capturing data with the OSMOCOM with no modification.

Thanks again
Florencia

Hi Jon, thanks for your response.
Thanks for the GPIF explanation. We had seen that the GPIF changed some bits of the RESERVED BYTES and we are thinking in not using them for the time being. But it's useful to know in case it's needed we can count on those extra modified bits.

In reference to:

I'm a little unclear about you mean here. If you're modifying gr-osmosdr, you're interacting with libbladeRF. I assume you're modifying libbladeRF to extract the data you'll be placing into the reserved and flags fields?

We only modified the gr-osmosdr. We are obtaining the data from the reserved and flags' fields by receiving a message and inspecting the first bytes. This means the metadata is received as part of the rest of the samples.
After receiving with this block we are planning on implementing a new block on GNURadio to process data depending on the metadata bytes' value in order to handle data to the following blocks on the project.

Thanks again,
Florencia

From going over the libbladerf documentation regarding the functioning of the metadata, specifically to schedule TX/RX, it seems that it should be possible to schedule TX/RX routines that are dependent on each other. Am I correct in assuming this? E.g. TX a 2ms pulse every 10ms, and RX for the 8ms downtime.

Hi Jon, thanks for your reply.

jynik wrote: I believe it should be possible to have the RX and TX counters synchronized +/- 1 clock cycle.

If I remember correctly, the FPGA clock runs at 100 MHz, is that correct?

jynik wrote: There is a single timestamp enable bit from the FX3 -> FPGA that is turned on with the first bladerf_sync_config() call that enables timestamps. This implies that you'll want to have the sample rates already setup up before your bladerf_sync_config() calls (for either module), otherwise your counter would have drifted since it was operating at a different rate for some amount of time.

So, a call to bladerf_sync_config() will start the free-running counter from which the timestamps are derived? Does this mean that the TX and RX counters are inherently offset by the time it takes for the bladerf_sync_config() to complete for each module?

jynik wrote: It sounds like you're working on some sort of TDD application? If your uplink and downlink are on the same frequency, I would advise you to ensure the RX and TX frequencies on the bladeRF are tuned at least 1 MHz apart, and digitally mix to the target frequency. I say this because we've found that if the PLLs in the LMS6002D are tuned within 1 MHz of one another, they may begin interfering with one another.

I'm developing a simple DRFM, but to do so I need a test radar. I have developed one before, but this was before metadata was introduced into libbladeRF, so there were some issues with TX/RX synchronization. What exactly do you mean by the PLLs interfering with one another?

Hi Jon,

Thanks, your comments are indeed extremely useful.

So essentially, I don't have to worry about individually configuring module timestamps since they're synchronized within +/- 1 clock cycle through the way they're defined. That also means that it doesn't matter whether I wait for a particular timestamp between RX or TX, since they both are synchronized, making it much simpler to schedule TX and RX bursts based on predetermined time intervals.

I'll update this thread if I come across anything interesting.

Sincerely,
Jaco