 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Don't use the WS2040-Zero with MMBASIC.....
| Author | Message | ||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9889 |
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! |
||||
phil99 Guru  Joined: 11/02/2018 Location: AustraliaPosts: 3042 |
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. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10998 |
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 |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8618 |
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. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 1751 |
This is why I prefer an external watchdog. |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9889 |
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! Smoke makes things work. When the smoke gets out, it stops! |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9889 |
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. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9889 |
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 Smoke makes things work. When the smoke gets out, it stops! |
||||
| grumpyoldgeek Newbie  Joined: 30/07/2018 Location: United StatesPosts: 40 |
The ninth harmonic of 48MHz is 432MHz. Might be close enough to 434MHz to be the problem. |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2026 |
