I have had a hell of a week.

ONE unit of hundreds, went rogue and transmitted a constant 100% duty-cycle "Dead-air" signal inside one of my networks.

This had the effect of totally preventing any other node on that frequency(434.650MHz) from being able to send their messages through to the base station.

This was cos the "Dead-air" signal from the rogue, was basically swamping the receiver, and none of the genuine calls could make it through.

The controller in this case, was the WS2040-Zero module, and I have historically had many issues with MMBASIC stability on this thing.   To the point that I now have MY OWN module based on the PIC32MX170 chip and standard MM2 firmware, that uses the WS2040 Zero footprint, which NEVER gives any issues.

Anyway, this was quite an interesting technical problem.
As the WS2040 module had gone rogue(crashed), this particular module decided that during that event, it would hold the ENABLE line to the transmitter high - permanently.

There was no data, just a dead-air carrier on 434.650MHz.

This caused an amazing amount of problems, as all the other units on that frequency could then NOT transmit their message due to the 100% dead-air carrier caused by the rouge unit.

I had to call in the radio inspector, to track down where the problem was, and it was a unit controlled by a WS2040 PicoMite unit that had crashed.

It was promptly removed and replaced with a RT2040 module using the standard MM2 chip, and there has been no problem since.  

I don't consider the PM firmware on the WS2040-Zero to be stable at this point.
I have had to remove SO MANY WS2040-Zero module-based units now, it is insane.
MOST of them simply crash and won't respond at all, but now I am getting units that when they DO crash, they hold the transmitter enable line high, causing......well...

This is NOT to rain on the PicoMite development etc, nor the code, but when used with the WS2040-Zero module......it is not stable long term, and in fact, can cause all kinds of Mary-hell.    

DO NOT USE THE PICOMITE FW with the WS2040-Zero MODULE, for any kind of 24/7 thing.

---

Smoke makes things work. When the smoke gets out, it stops!

As you already have a reliable solution you probably don't need these ideas but if you want to prevent this happening with the remaining WS2040-Zeros...

1) If the input resistance of the transmitter is high enough capacitor coupling from the WS2040-Zero may work. A high value pullup/down resistor will prevent the TX running longer than the cap. charge or discharge time. If necessary reverse diodes to Vcc and Gnd will keep the TX input within limits.

2) If that isn't suitable a NE555 one-shot timer between the cap. and the TX will cater for lower TX input resistance and longer timeout.

  Quote  

Don't use the WS2040-Zero with MMBASIC.....

Don't you mean to add "with radio transmitters"? From everything you report doesn't it look like it is the radio transmissions that are interfering with the RP2040 processor? The radio and cpu frequencies are in the same area and any unshielded cabling in the order of 17, 34 or 69cm is going to act as an antenna potentially injecticting RF into the RP2040. The MM2 is running and much slower and therefore much more likely to be immune

T suspect it's an RF problem too. I've had quite a few RP2040-Zero modules now (more likely counterfeit ones as they aew very cheap) and not had a single problem with any of them. For small stuff it's my go-to module. Or is this a different one?

You don't need much supply, GND or GPIO wire to act as an antenna at that frequency. A quarter wave whip is about 175mm and that will transmit and receive wonderfully. :)

This is why I prefer an external watchdog.

  matherp said  

  Quote  

Don't use the WS2040-Zero with MMBASIC.....

Don't you mean to add "with radio transmitters"? From everything you report doesn't it look like it is the radio transmissions that are interfering with the RP2040 processor? The radio and cpu frequencies are in the same area and any unshielded cabling in the order of 17, 34 or 69cm is going to act as an antenna potentially injecticting RF into the RP2040. The MM2 is running and much slower and therefore much more likely to be immune

Yes, I accept that alteration in my statement.    

Sorry everyone - I was still a little stressed by the entire event, in case you did not pick up on that.    

But yes - probably much fairer to say don't use them with RF projects.

I wonder if a standard Raspberry Pi 2040 module would have the same issues?
For the purposes of experimentation, I might rig something up on the bench just to see.

Also, I wonder if a custom-made sheild can around the WS2040-Zero module would help stop this kind of thing?  Not that it matters, really, as I have gone back to the 170 MM2 chip anyway.

I have a saying I like to quote to people: "Technology is great when it's working!"  

IE: You find out just how dependent you are on it, when something fails!

  PhenixRising said  

This is why I prefer an external watchdog.

When I had the issue with the modules just crashing(but not causing a dead-air carrier), that was one thing I and other members looked at in a thread about the problem, but the main issue, was that the WS2040-Zero module, did not route out the RUN pin on the 2040 chip, so there was no way to EASILY connect any form of external watchdog.  

  matherp said  

The radio and cpu frequencies are in the same area and any unshielded cabling in the order of 17, 34 or 69cm is going to act as an antenna potentially injecticting RF into the RP2040.

I hear what you are saying, but this confuses me.

The PM manual, page 19 under Clock Speed, states that the standard PM runs at 200MHz by default.  That is less then HALF the frequency of the RF module, and it is not even in the same band.  200MHz is basically VHF-H, and 434MHz is UHF, so I do wonder how one could have any effect on the other....      

In my use of them, I had slowed the clock down to 48MHz to save power if they switched to backup-battery.
That means that the PM frequency and the RF module frequency, are 386MHz apart - that should be MORE then plenty to prevent one from upsetting the other.

Perhaps you or any other member could clarify.
Edited 2026-03-01 14:41 by Grogster

The ninth harmonic of 48MHz is 432MHz.  Might be close enough to 434MHz to be the problem.

NINTH harmonic?!?!!??  

I though nothing was really relevant past the 3rd or 4th harmonic.

Might have to power up a WS2040-Zero @ 48MHz, and check that, but I would have thought that a NINTH harmonic, would be so far down into the noise-floor, as to be totally un-readable.

Hi,

Depends on a number of factors; odd-harmonics are often culprits (signal compression and rectification products) and you might just be unlucky that a trace or lead length just nicely resonates and becomes an effective antenna.

Speaking as a 30+ year veteran of the EMC industry who builds harmonic signal generators for a living.  

  Grogster said  

NINTH harmonic?!?!!??  

I though nothing was really relevant past the 3rd or 4th harmonic.

Might have to power up a WS2040-Zero @ 48MHz, and check that, but I would have thought that a NINTH harmonic, would be so far down into the noise-floor, as to be totally un-readable.

I'd start by attempting to shield the Pico in a metal box if there's much RF.
All wires should pass through ferrite beads, best held on by looping the wire through twice. You could use feedthrough capacitors but they are awkward to use and harder to find. You could have other directly connected electronics such as an LCD display and/or SDcard socket in the same box, that would save on external connections.

Another way is to move the TX and antenna far enough away from the Pico and filter the connections to that. The antenna should be outside a metal box containing the rest of the bits and the TX may have to be screened unless you can get the antenna connection very short.

Likkle micros and RF don't generally mix well.