Porting on ESP32

[forty76]

I try use MicronetToNMEA on ESP32. I know exist other solution as Micronav(not working) or esp32Micronet(to old and compile error).

I like MicronetToNMEA, it's full featured and up to date.
I try to use basic function in MenucalibrateXtal, by change MicronetToNMEA CC1101Driver and RfDriver. For now remove timerHandler function (It is only for trasmit).

ESP32 give trouble in capture interrupt
original ISR function is

void RfIsr() {
gRfReceiver.RfIsr();}

even though the function is activated it does not activate gRfReceiver.RfIsr()

I can currently work around the issue using a FreeRTOS task that call gRfReceiver.RfIsr();
my code is

void RfIsr() {
dt = true;}

void BlinkTask(void *parameter) { for (;;) {
if (dt = true) {
gRfReceiver.RfIsr(); dt=false;
} vTaskDelay(1000 / portTICK_PERIOD_MS);
}}

I inspected the Micronav code to understand how interrupts are handled, but they moved ISR management from RfDRiver to SX1276MnetDriver, so I would have to significantly modify CC1101Driver.

Can anyone advise me on how to call gRfReceiver.RfIsr(); directly from void RfIsr() ?

[Rodemfr]

Hello Forty,

Sorry for the very late reply. Porting to the ESP32 is not an easy task. Interrupt handling is very different, and the SPI drivers don’t behave the same between the Teensy and ESP32 implementations. It took me quite some time to get a working version of MicroNav.

I’ve ported MicronetToNMEA to a uPesy Wroom DevKitC (based on the ESP32-WROOM-32 module). It seems to be working fine so far — only the LSM303 hasn’t been tested yet. You can find it in the esp32_hardware branch. In theory, it should work with any DevKitC board based on WROOM modules.

I’m also preparing a dedicated MTN hardware PCB, which you’ll find in the hardware subdirectory. It is an EasyEDA Pro file. Be aware that it hasn’t been reviewed or debugged yet, so it is likely non-functional for now.

[forty76]

HI. I have write new code. Now after more change it work
I have read your documentation in micronet.txt and ybw forum. I'm having trouble calculating the transmission windows.
I solved it by empirically determining the transmission windows and then I determined the algorithm for the calculation. Can You explain me your algoritm to calculate trasmission windows ?

Question 1
where is first transmission window?
I test it and not start at end of Message 0x01 (Master Resquest). From GDO0 rising I measured
Number Device beyond MR time from GDO0
1 767
2 1257 +490
3 1753 +496
4 2250 +497
5 2965 +715 ------------
6 3470 +500
7 3970 500
8 4437 467
9 4929 492
10 5416 487
11 5894 478
12 6383 489
13 7121 738 ------------
14 7610 489
15 8097 487
16 8575 478
17 9017 442
18 9575 558
19 10043 468

Question 2
transmission windows algoritm
(16 +MR_byte)x104 --> Rounded --> +243/244244 --> + 3416 (14244)
Async windows 7076 (29 * 244)

you have declared
| preamble | 0x99 | Micronet message | Guard time | 244us rounding |
|---------------------------------------------------------------------------|
| 1771us | (14 + PL) * 104us | 1893ms | 0-243us |

but preamble = 15+1 byte --> x 104 uS = 1664

[Rodemfr]

The function that calculates the transmission windows is MicronetCodec::GetNetworkMap() (line 1013 of MicronetCodec.cpp). The specification of the transmission windows was developed empirically, but it seems to work reliably so far.

the 1771us value is in fact preamble + sync byte. this is confusing...

Here are the points you should pay attention to:

• Time reference: In the MTN code, the first slot starts at the end of the Master Request message. The end of this message is determined from the “FIFO threshold” interrupt and includes the guard time. This is computed in the RfDriver::RfIsr_Rx() method.

• ESP32 timing constraints: On the ESP32, you must use SPI within an interrupt context to avoid being delayed by other interrupts, which can introduce several hundred microseconds of latency. If you don’t, your code will miss the transmission window.

• SPI speed considerations: Depending on the SPI clock speed, you may also need to account for the time required to fill the CC1101 FIFO and start transmission, which can take several tens of microseconds.