Closed Pascal66 closed 8 months ago
//shortcut here for packets less than max fifo size
Also this shortcut way is crazy
I've to use the "slow" way.
According to the specification length must be 1 byte:
In your read_payload_batch you can add device->packet[0] = value; ...And : device->packet[++device->fsk_ook_packet_sent_received] = value; // device->fsk_ook_packet_sent_received++;
This permit to return ALL the FIFO and not the FIFO less than the first byte.
Yes, but this will make API inconsistent:
uint8_t *data
that was set in sx127x_fsk_ook_tx_set_for_transmission
should be received as-is in the RX callback.Some need the entire FIFO, not truncated of the first byte. in your inconstitent API parts, it can be modified according this first byte. "More we have, more we can" Btw, I rewrited it for my need Thanks.
FIFO problem is resolved, using a spi_device_interface_config_t dev_cfg = { .clock_speed_hz =4000000, ... Speed after 16MHz are wrong and need mode_1 and not mode_0 for both VSPI or HSPI with SPI_DMA_CH_AUTO
Same for Heltec or LilyGo
Rewrited the 3 modes: Normal, Burst, Fifo
I also noticed when I used SPI speed ~8Mhz, data gets corrupted. I guess my ESP32 is not fast enough or crystal is not stable enough to generate good 8Mhz SPI signal. Some bit might flip when you send long sequence of "0" or "1". It can be solved by sending scrambled data.
Both ESP32 (lilygo & heltec) are 240MHz. Not related. The SX1276 with SPI & DMA is at 10MHz and mode 0 You choose the right value with 3000000 (even it's better to use a multiple of 16)
The SX1276 with SPI & DMA is at 10MHz and mode 0
Then maybe this is causing such issue. I don't have oscilloscope with ~16Mhz sampling rate to check that. Even if SX1276 rated at 10Mhz, it is not clear how they got this number. Maybe they used external TXCO with ~1ppm (connected to XTA pin). I think it depends on how the chip is connected to the rest of the board. Internal sx127x crystal is 20ppm.
My received frames are always truncated of the first byte. This is because you remove the first byte, considering it's only the packet_length stored on it in the case of VARIABLE.
In my implementation, my first byte contain not only the packet_lenght and other flags on it.