Fix Special/Flood jam duty cycle: 26% → 85%
Root cause: transmit() wraps startTransmit()+finishTransmit(). RadioLib's finishTransmit() has a timeout of (1/bitRate)*128 = 0.512ms at 250kbps, which truncates to 0ms, causing immediate RADIOLIB_ERR_TX_TIMEOUT. The CC1101 was transmitting its 2.59ms packet correctly, but the 10ms inter- packet guard meant 7.41ms of dead air — only 26% duty cycle. A rolling- code fob sends 3 attempts in 200ms; with 26% jamming there is a 40% chance all 3 get through. Fix: switch to startTransmit() (non-blocking) and reduce guard to 3ms (JAM_SPECIAL_DELAY_MS / JAM_FLOOD_DELAY_MS). CC1101 finishes the 2.59ms packet autonomously and returns to IDLE. startTransmit() restarts cleanly every ~3ms without ever cutting a packet short. Duty cycle: ~85%. Made-with: Cursor
This commit is contained in:
@@ -64,7 +64,11 @@
|
||||
#define JAM_FLOOD_DEV_R1_KHZ 140.0f
|
||||
#define JAM_FLOOD_DEV_R2_KHZ 200.0f
|
||||
|
||||
// Special jam: 60-byte random payloads with 10ms delay (cypher-pulse exact clone).
|
||||
// Special/Flood jam timing: CC1101 at 250 kbps takes 2.59ms to send a 61-byte packet (preamble+sync+data).
|
||||
// 3ms restart gap allows each packet to complete naturally before startTransmit() is called again.
|
||||
// Duty cycle: ~85%. 10ms (original cypher-pulse) only achieves 26% — too many gaps for rolling-code fobs.
|
||||
#define JAM_SPECIAL_DELAY_MS 3
|
||||
#define JAM_FLOOD_DELAY_MS 3
|
||||
|
||||
// SmartRF-style dump: config space only (TI SWRS061); PATABLE/ strobes not included.
|
||||
#define CC1101_CFG_REG_LAST 0x2E
|
||||
|
||||
Reference in New Issue
Block a user