Add support for 4 simulatenous Lighthouse basestations to the LH2 bsp

[SaidAlvarado]

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:

• Add support for basestations mode 3 and 4
• Rewrite the data structures to handle a changing number of visible basestations.
  • Maybe by storing all the polycounts in a big array as well as a timestamp of how old is a particular measurement.
• Rewrite DotBot radio protocol to be able to send a variable number of lighthouse's data.
• Open a similar issue on PyDotBot to update the DotBot Radio protocol on that side.
• If there is time, attempt to improve the poly search.
  • by saving the last calculated polycounts and using them as an additional checkpoint.
  • by counting the LFSR both forward and backward.
  • By increasing the number of checkpoints to 32.
  • Change the _demodulate_light buffer to be 64 bits instead of 128 bits. This should speak up the demodulation quite a bit,

[SaidAlvarado]

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 ?

[SaidAlvarado]

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.

[SaidAlvarado]

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

[SaidAlvarado]

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.

[SaidAlvarado]

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.

[SaidAlvarado]

Small detour to fix #270

[SaidAlvarado]

Benchmark 11-Jan-2024 - 1:

• SPI ISR: 11.45 us +- 15 ns
  • _add_to_spi_ring_buffer(): 10.55us +- 10.5 ns
    • (original code was 8.3us)
  • db_timer_hf_now(): 711 ns +-9.9ns
  • db_lh2_4_process_raw_data(): 15.04 ms +- 23.63 (min: 4.7, max: 95.3) (74/1185 error vs. good poly) ( the poly errors cause the 95ms worst case.)
  • demodulate_light(): 1.37ms +- 29us
  • select_polynomial(): 17.0ms +- 27.1ms (min: 3.12, max: 90.0) (78/793 errors)
  • process_location():
  • reverse_count_p() 44.59ms +- 29.26ms (min: 1.6 max: 98.27)

Notes:

• In determine_polynomial() there is a meaningful difference in starting at start_val =0, vs. start_val =9

  • mean: 21ms max: 84ms, min: 3ms. vs. mean: 13.5ms, max:63.2, min:2.6ms

• 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

[SaidAlvarado]

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.