Cardputer ADV + Lora Cap doesnt seem to send _any_ LoRa at all

[gabuzom]

Thanks again for this very promising and exciting piece of software!

I tried to announce with the exact same radio settings, and none of my 2 other LoRa nodes would ever catch it.

I tried to fiddle a bit with radio settings... still nothing

(I shall add that the settings on my network are custom: 869.475Mhz, 125Khz BW, SF 8..)

-> I then decided to fire up an SDR and saw the following:

• nice "fire" whenever one of my 2 other LoRa nodes would announce
• nothing at all when rsCardputer would announce, whichever the radio setting was.

To make sure it wasnt a HW issue, i fired up Meshcore on the Cardputer, and upon announce, "fire" on the SDR

So it seems like a software issue... how could I get more information to help diagnose this?

[gabuzom]

I tried again with the standalone version of v.2.0.1 and the issue remains.

When i press announce i merely see a blip on the SDR, but interestingly, if spamming the "announce" button, i see some vague signal forming, increasing over time, but not looking at all that the expected signal (as seen when one of the rnodes on my networks does an announce)

Here is what it looks like pressing 3 times "announce" and waiting 1 sec. (the dark bars with a vague "blip" below) and then spamming the announce button (the sorta "cloud" above):

[gabuzom]

For comparison, this is what signal looks, on same SDR and same settings, when an rnode on my network (with same radio settings) does the announce:

[gabuzom]

(Also, if relevant and if wasnt obvious from the rest because of misleading title, device doesnt seem to also be receiving any LoRa announce by other devices on the same settings...)

[gabuzom]

More tests, and.. it's surprising!

• I set one of my rnodes, for testing purposes, to "long fast" and default of 868MHz;
• i deleted the ratcom folder on the SDcard to restart afresh;
• on first try announce was seen by my rnode!! miracle! my first over-the-air exchange between rscardputer and any other point of my network! <3 i tried with a few messages both ways and everything functioned well;
• rebooted the rscardputer, and no message or announce was ever seen again. ://
• (this is when i bumped into messages failing to send in a non-obvious way #18 again, as nothing told me it wasnt possible to send a message...)

so my temporary (and uneducated) conclusion is that it is indeed a software issue, and it looks a hell of a lot like #14

tell me if there is anything i can do to help with further diagnostics!

[gabuzom]

Wow incredible!

Somebody on the Discord (!) suggested, and i updated my settings for 65500Hz bandwidth instead of 125000, while my other rnodes are set to 125000, and it seems upon first tests that comms are now working between them, at least from cardputer to other rnode!

[gabuzom]

Only worked in one direction.... and until next reboot...

intersting fact: on next reboot, main screen showed "125000Hz" while the setting had been set to 65500... and showed 65500 in the settings menu.

so there is def. something fishy here it seems.

[0x00001312]

I think what you're hitting is a real bug in the SX1262 driver, not your radio settings or hardware. Ran into the same thing on a downstream fork (rsCardputer-CE) and tracked it down.

Some background on how this firmware handles frequency: it boots the LoRa chip at a hardcoded default of 915MHz (Americas), then once your saved settings load from storage, it calls setFrequency() again with whatever you've configured, in your case 869.475MHz. Moving to a frequency in a different ISM band requires the chip to run an image calibration step (CalibrateImage) for that band before the new frequency actually takes effect on air. That calibration only runs once per band; the driver caches which band was last calibrated and skips the step on repeat calls to the same band.

What I found in the driver: there's a gap between issuing an opcode like CalibrateImage and the chip's BUSY line actually rising to show it, and on top of that, the driver's busy-wait helper (waitOnBusy()) only polled BUSY for up to 100ms before giving up, whether or not the chip was actually still busy. CalibrateImage on a fresh, never calibrated band can run long enough to hit both of these. When the cap got hit, the function returned while BUSY was still genuinely asserted, and the SX1262 ignores SPI commands sent while busy. The next thing the driver does after calibration is write SetRfFrequency with the real target frequency, and that write landed on a still busy chip and got dropped without any error. The chip stayed on 915MHz. Nothing in logs or software state shows this, since the calibration step gets marked done (the band is cached) even though the frequency write right after it never applied.

That lines up with the pattern in your thread: wiping the SD card and testing fresh worked once, then broke after a reboot. It also explains why re-confirming any radio value in Settings "fixed" it temporarily. That second call hits the cache, since the band is already marked calibrated, skips the calibration step entirely, and just reissues SetRfFrequency on an idle, non busy chip. That write goes through fine. So the workaround you and the folks on Discord found isn't fixing anything, it's avoiding the broken code path.

Fix is in SX1262.cpp: a short settle delay before polling BUSY right after issuing CalibrateImage, and raising the waitOnBusy() cap itself from 100ms to 1000ms, well above any documented SX1262 opcode duration. Both probably play a part here. Landed on rsCardputer-CE as of v0.0.5 (commit 5e03e0d). There was an earlier, related attempt at this in a2ffda0, which fixed a different bug in the same calibration function but wasn't the whole story. Upstream here doesn't have either fix yet.

On the bandwidth reverting after reboot you noticed, that goes through a different opcode (SetModulationParams, not calibration), so I can't say for sure it's the same root cause, but it shares the same waitOnBusy() helper, so it's plausible it's the same class of bug rather than something separate. Not claiming that one without testing it directly.

If you want to confirm this is your bug specifically: after a clean boot with your custom frequency already saved, reproduce the no signal issue, then go into radio settings and reconfirm any value, even the same frequency, without rebooting. If that fixes it until the next reboot, this is almost certainly it.

[gabuzom]

Wow! you are my hero today! Such an amazing journey! Such clever finds! Wow! Much amaze!

Unfortunately, your suggestion of changing the value without rebooting doesnt seem to produce any change... will try again in various ways and we'll see...

I am confident that you are up to something though, congratulations! (and thank you!)

[0x00001312]

Thanks for testing that, glad my rambling at least made for a fun read.

Going back over this, the reconfirm-without-reboot test doesn't isolate the bug I pointed at the way I implied. There are two separate calibration bugs in that part of the driver, and they predict the same "reconfirm masks it" pattern, not different ones: calibrate_image() was issuing CalibrateImage from STDBY_XOSC instead of the STDBY_RC the SX1262 datasheet requires (I fixed that one first), and separately waitOnBusy() capped its poll at 100ms — too short for CalibrateImage on a fresh band — so the SetRfFrequency write right after it could land on a still-busy chip and get silently dropped (fixed second, same day). Both leave _imageCalBand marked as cached for the new band even though the calibration didn't actually take, so any later call, including a reconfirm, just skips recalibration and reissues a clean SetRfFrequency on an idle chip. I just checked upstream directly — both are still there unfixed.

On my own hardware, fixing the STDBY_XOSC issue first didn't get me a working link by itself — it stayed unreliable until the waitOnBusy fix landed a couple hours later, so it took both for me, not one or the other. Which makes your result more interesting: if reconfirming does nothing for you at all, instead of temporarily fixing it like the masking pattern predicts either way, something else may be going on for you specifically.

I'll try to get a PR up for both fixes upstream regardless. If you get a chance to test rsCardputer-CE (has had both since v0.0.5), that'd help narrow it down on your hardware.

[0x00001312]

Opened a PR with the fix: #21

Tested on my own device across multiple frequencies (915MHz boot default, then switching to a few different configured frequencies in the 868MHz band), each after a clean reboot — comes up correctly on the new frequency every time now, no need to reconfirm any setting afterward. RX has been working fine too, no missed announces in either direction since the fix.

Worth being explicit about why this is bigger than the Settings-reconfirm workaround: SetRfFrequency sets the tuning used for both TX and RX on this chip. The actual bug isn't a wrong frequency being computed — it's the write that changes the frequency getting silently blocked, because it lands on the chip while it's still busy finishing image calibration from the band switch. The chip just never receives the command, so it keeps running on its old frequency in both directions until something else (like reconfirming a Settings value) happens to land a clean write on an idle chip afterward.

On why reconfirming without rebooting didn't do anything for you specifically: this bug is a timing race, not a guaranteed failure every time — whether the write actually gets dropped depends on how long CalibrateImage takes on that specific chip versus the (too-short) polling window, which can vary run to run. It's possible your boot-time calibration happened to land within that window and actually succeeded, meaning the frequency was already correct and there was nothing for the reconfirm to fix — in which case whatever you're hitting may be a separate problem layered on top of this one. Can't rule that out without testing on your exact hardware.