What will be the most simple way to trigger RX stream from LimeSDR using Soapy SDR examples using a external trigger pulse to GPIO (using let’s say 1 PPS from a GPS module) ?
Hello All,
I am trying to receive a LTE or 5G signal frame-synced to a trigger input. I was thinking of providing a 1 pps out from a gps module for this purpose.
I have referred to this:
to start with, where two LimeSDRs are synced using EGPIO pins.
Using the changes above, I see that the RX stream is triggered correctly using a trigger input to EGPIO(1), but the IQ samples are incomplete after certain number of samples.
I am not very good with the Gateware repo, but I am trying my best to understand it.
Can anyone provide any insights into this? If anyone has made it work or has some idea to make this possible? Or has faced some issues while trying this out?
I am not sure I can be of help because I am not using Soapy SDR. However, I can say that the synchronization works perfectly for my purposes. However I am only acquiring a limited number of samples - at most 0.5 seconds worth of samples at 10 MHz. Perhaps due to my limited acquisition time there is an issue I do not observe.
Could you please elaborate on what you mean by “IQ samples are incomplete”? Are you seeing missing samples or incorrect values?
This sync mode using EGPIO(1) works as a STREAM enable rather than stream TRIGGER, this means stream is enabled when EGPIO(1) goes high and also it gets disabled when EGPIO(1) goes low.
From software perspective, the hardware stream should remain enabled for the entire duration since start. Otherwise disabling stream while the software is transfering data will mess up USB data transfers and expected data alignment.
Yes, I think the HW counter/timestamp is showing inconsistencies/per iteration. Requested number of samples is configured as 38400 and following are the timestamp readings:
The PPS signal connected to EGPIO(1) is constantly toggling. Each time it toggles, it effectively stops and restarts the stream on the FPGA side. As Ricardas mentioned, this behavior is not expected from the software perspective and causes issues with packet alignment.
Could you explain your application a bit more?
Are you trying to capture data based on a single trigger — meaning you start the stream in software, capture a certain number of samples after a trigger is received, and then stop the stream?
Or do you need to capture samples for multiple trigger events over time?
EDIT: I just read your first post and I understand that you want to capture multiple times, synchronized to repeated trigger events. In this case current GW implementation is not going to work that way.
Ok. I understand but do you think I can modify to detect a rising edge of the pulse to enable enable RX using may be rising_edge(EGPIO(1))?
Or may be its not that straightforward?
If the goal is to trigger the stream start on the rising edge of EGPIO(1) and then continue capturing samples without needing further triggers, that should be a relatively straightforward modification. I can take a look to see what would be involved.
If instead you need to capture a specific number of samples on every rising edge of EGPIO(1), that would require a more substantial change.
Just to note, I’m not committing to working on this immediately, but I’ll try to assess what would be required.
