Hello, I am trying to estimate multiple targets that are transmitting burst signals every 30-40 ms. I am tracking two frequencies (2 VFOs) at the same time. Thus, every 30-40 ms a transmitter transmits and in the next 30-40 ms another one (we may sometimes have transmissions at the same time by more than one transmitter but it is very rare and I don’t take it into account). My first idea is to minimize the block size to have as many as possible estimations so I have tried block size of 54 ms however If I measure the inter-estimation time for each one of the two VFOs is around 350 ms. Then If change the block size to 436 the inter-estimation time is around 1300 ms. Then If I change the block size to 100 ms the inter-estimation time is around. Any idea why this happens?
P.S I will take another look If I missed something in inter-estimation time calculation. I just subtract the current timestamp and the previous timestamp and averaging.
If you’re recording CSV DOA data you’ll need to increase the polling rate as by default it only polls the output every 1s. You didn’t say if you’re logging via the web interface, or via the Kraken App, but both methods have settings for the polling period.
Also beware that if you set the block size too small you can run into other problems. Consider what happens if the signal comes in on the boundary of a block, which is more likely if the block size is small. Then you’ll have the energy spread over two blocks which can significantly reduce the total SNR available in an already short signal. So it’s probably better to keep the block size a bit larger.
Also the time might depend on what computing platform you are using. If it’s Pi 4, it may not be able to keep up with a faster block time, and hence some blocks will be dropped. So use a Pi 5 if you can.
Thank you for your response. Indeed, I forgot to mention how I do the logging. Each time an estimation is ready I am writing the data to a redis (something like the [full post](krakensdr_doa/_sdr/_signal_processing/kraken_sdr_signal_processor.py at 84318ce6d4fe2dfe58c359f40546488885a0c43b · krakenrf/krakensdr_doa · GitHub without the time_elapsed). What is the minimum block size that you suggest for Pi4 based on your experience? I am using jetson or pi4 and I see that in the most cases using block size of 50 ms the Update Rate in GUI is smaller than 50 ms (of course sometimes -especially in pi4- the Update Rate is greater than the block size which means that some packets are lost but it is not very often). Finally, If I lose a signal due to a dropped block or because it was received at the boundary of a block, it’s not a major issue. Within a few seconds or minutes, there will be another transmission, allowing me to continue. Statistically, I’ll eventually capture the signal at some point.
I would choose a block size about double the expected signal burst period. Having a short burst of a signal within a larger block doesn’t affect SNR and DOA performance too much.
Nice that is what I am doing in most cases. What about the inter-estimation time? Any idea on why is this affected when changing the block side? In theory, I would except that if I have burst signals every 50 ms then if choosing block size 436 ms the inter-estimation time would be 436 and not something 3 times more like 1300
According the UI notes when the Update rate is larger than block size then we have block drop. What about the latency? Can this be larger than block size?
In my case, I do a POST to a Redis dB every time a new DoA estimations is performed. Is it better for performance to somehow collect multiple estimates and do a POST once in a while like writing to the csv file (which use a time interval)?
Latency can be higher than the block size because latency is just the time it takes for the block to get through the system. But if the update rate is larger then that means some blocks are being dropped.
I don’t think it matters if you write to your DB every time or in bulk. The update rate and amount of text data isn’t big enough for that to take any significant time.
I’m not sure why you’re getting 3x the block size for interestimation. If you reduce the write interval to a small value, and look at the timestamps in the CSV file you should see that they are about a block size apart each time, so I don’t think it’s anything to do with the actual kraken code.
I found why the inter-estimation time is not equal to block size. In many cases the inter-estimation time is equal to block size but there are times that can be two or three times the block size which leads to average inter-estimation time>block size. I assume this is due to block loss