Closed SaidAlvarado closed 5 months ago
Questions for @aabadie. In lh2.c why is the spi_rx_buffer[64], but the lh2_buffer_t[128] ? the former gets directly copied into the other, why is the latter so big ?
Remember you hardcoded the value of the lighth imlementation .c file in bsp/bsp.emProject
<project Name="00bsp_dotbot_lh2_4">
<configuration
Name="Common"
project_dependencies="00bsp_timer_hf"
project_directory="."
project_type="Library" />
<file file_name="nrf/lh2_4.c" />
<!-- Remember to change this back to nrf/$(Lh2ImplementationFile) -->
<file file_name="lh2_4.h" />
</project>
Change it back when you're done.
SEGGER fails to build any project when the nRF53 solutions are selected (tested with DotBot v2, and nRF53_App solutions). It gives no description for the error, it just says it failed. I checked that the SEGGER Nordic package was up to date.
Ask @aabadie for help next monday, for now, work on the nRF52DK
Ask @filmak why the function demodulate_light() requires a 128 byte sample buffer, when the SPI is only programmed to read 64 bytes. There should only be 64 bytes worth of information arriving in that buffer.
In _determine_polynomial()
, most errors occur in the first 2 bits of start_val
.
If you set start_val
to 3
and bits_N_for_comp
to 47-3
, the amounts of times the microcontroller needs to redo the weights computation is severely reduced.
If you set start_val
to 9
, it almost never has to redo, except in the case of a poly error.
Small detour to fix #270
In determine_polynomial() there is a meaningful difference in starting at start_val =0, vs. start_val =9
with the LH at 30cm the error rate is 16%, with the LH 1m away the error rate is 1.8%.
The worst case error takes 60ms in both cases. There is almost no middle ground, either you get it in the first iteration, or it's a Poly error. There might be a faster way of detecting PolyErrors early, so you don't loose that much computing time. (Do try to test at different distances, we don't want to accidentally make the system worse a long distances.)
The hamming_weight() and polycheck() take 300-200us, is not much, but they are run a lot, so it might be worth trying to optimize them, maybe assembler?
Single lighthouse operation causes almost no poly-errors. no errors in a 1min run, and only 13 non-single-iteration polynomial finds
Note, I don't know how, in one occasion during testing reverse_count_p got stuck because the lsfr buffer reached 0x0000 and then got stuck there forever. Add an emergency condition to check for that and return an error.
For the experiment with mobile lighthouse basestations we need the DotBots to be able to receive beams from 4 lighthouses at the same. Not necessarily process them all, but at least support polynomials from mode 3 and 4 of the basestations.
Tasks: