I’ve been building radiator controller using the RFM69pi which has been working well.
It uses:
3 - DS18B20
2 - PWM outputs for fans
2 - Flow sensor
2 - Relays to control power and ball valve
Runs of 12V with a 5V and a 3.3V line
I’m now on my third mother board which is now simpler.
The problem is the device now locks up after about a 30 seconds to a minute but only with the new slightly improved motherboard. This is odd as this happens with no devices connected. I’ve changed everything that’s left (power regulators) but the issue is very consistent. I move the RFM69pi between the two motherboards (my old design and the new design) and the new version always locks up. I’ve checked the board many time but can find no issue with any connections.
When I connect a Pi to the serial line to check what may be going on it works fine.
So the only thing I can think of is that I can’t leave the serial line unconnected. The original green connector simply floats above the mother board without any connection. I can only think that this is receiving noise causing it to lock up. Once it locks up, which I can tell because the red led stops flashing for more than a minute, if I then connect a Pi to the serial line then the device seems to be dead. i.e. no output and no response to key presses.
So the question is: does the green connector need to be connected to anything and if so to what? Just to be clear I have soldered a header to the other side of the device so I assumed all the connections could be made from here.
I assume the three pins I would need to connect are:
6 - Ground
8 - UART TX
10 - UART RX
If I do need a connection what would I connect pins 8 and 10 to. Does 6 also need connecting to Ground.
I’m self taught and have no formal electronics training so I may be missing something obvious.
I simply don’t understand how a slightly different motherboard with the same connections can give this type of fault.
There’s very little substantial information here, you have the device in front of you and you know all about it. All we have is the few paragraphs above, even your previous posts presumably relate to its predecessor so they’re of very limited help to us; so don’t be too surprised if you don’t get very much help. We don’t know what your motherboard is like, what it uses of the RFM69Pi, and we’ve no idea of the processes it’s carrying out or the software it’s running.
My instinct is it’s a power supply, or its close relative, a grounding, issue. You wrote
What do you mean by that - that all the soldered joints are good, or that every track connects to where it should and only to where it should? Have you read about good circuit layout principles and put them into practice?
You also wrote
You need to think what changes when you connect the RPi? Are you supplying a ground or another ground, or another parallel power supply? Are you adding extra smoothing on a supply rail - or loading a supply rail differently? Are the supply rails at the correct voltage and noise-free?
Have you checked the circuit diagram? If you have, you should know what’s available on which connector.
The 10-pin connector is normally where it connects to the GPIO of the Pi, when we use the RFM69Pi and the RPi together as an emonBase.
What’s the software doing? Is it seeing noise picked up from somewhere on an input, reading it as a command or an input it can’t make sense of and it’s entered a loop it can’t break out of? Or waiting for something that never comes? How/where can it do that, and how can you prevent it?
In reality, the list of possibilities is endless, all I can do is point you towards a few things for you to think about.
Thanks for taking the time to reply on my issue. I think the problem was caused by the the poor quality of the PCBs I bought on ebay. I made another one with just the voltage regulator and RFM69Pi and this too exhibited same the problem. A breadboard version of the same circuit worked fine. I’m now using a different PCB boards and so far the problem hasn’t re-occurred.
I’ve uploaded some pictures. The one on the left works. The (hopefully) tidier middle version doesn’t and the minimal one on the right also fails. The two boards that don’t work are from the same PCB cut in half.
I don’t have much test equipment so not sure how to check for noise or whether there are ground issues. The only debug I have is connecting to the UART and when connected it works. When connecting to the pi I just connected the RX,TX and ground so perhaps this did improve the ground. Not sure why my ground would not be up to the job.
I’ve checked some websites about designing circuit boards but my board is very simple and a lot of the tips aren’t applicable to my board. I may be looking at the wrong sites.
The checking of the connections was using the audio buzz of a multimeter. Simply made sure the required routes connected and there was no unplanned or accidiental connections.
You misled me when you wrote “motherboard”. It never occurred to me for a moment that you were using stripboard. Our experience from the troubles other users have faced in the past is that you cannot get the same level of performance from stripboard as you can from a “proper” etched p.c.b. If no alternative is open to you, the suggestion I’d make is wherever possible, remove unused copper strips. Remember, two parallel strips are a capacitor - small but at the frequencies that we move the data around and modern devices respond, the capacitors are not so small that they can always be ignored. Also, remove all the flux from soldering. This can provide a high resistance leakage path which can cause problems too.
And again, as you mention, the substrate might not be the best quality.
I completed my new board (not strip but matrix) which requires wires instead of tracks. All was going well until I made a couple of changes and it also stopped working exhibiting exactly the same issue. I tried to undo the changes but still didn’t work. Again, connecting to the Pi fixed the issue but obviously not a workaround.
So considered again the problem of the serial line and my idea that there is noise on the line. Another odd thing is that occasionally the id or the network changes as though random data has eventually triggered this change. I had changed the code to switch off any menu option (i.e ignore it) which seem to stop the change in id and network but it still locked up. So I decided to go go all out and switch off the serial interface by simply commenting out the Serial.begin line and to my surprise it worked. All my boards now work and the latest one has been running for 5 hours+. If I need the serial for testing I can load a version with it switch on.
Now I have a workaround its gone from annoying to intriguing. I’m now considering how to test it further.
I think you have an unintended connection to the serial data you’re talking about. My points about stripboard obviously apply to the matrix board too, but to a lesser degree, because you still have a small amount of capacitive coupling between the pads, and the ability for the pads to reduce the tracking distance in the case of leakage paths across the surface of the substrate.
What you probably need to do is provide a pull-up or pull-down on the line that’s causing the trouble - a careful study of the relevant data sheet should tell you.
I have tried a 10K pull up using a jumper to the 10k used for the 1 wire resistor. This had no affect. I could try it again. The D0 and D1 lines are very short on the strip PCB. Almost nothing on the matrix. I’ll try soldering a pull on the strip board. Something to look at over the weekend.The strip boards that work seem exactly the same though.
Thanks
Ok, I’m just trying out a software fix which seems to be working and allows the serial line to work based on the converstation so far.
I simply PULLUP pin zero which I think is the RX.
e.g.
pinMode(0, INPUT_PULLUP);
If this is actually doing what I think its doing then my thoughts are as follows:
I have two PWM lines which may be causing a lot of noise. This could explain the issue if the RX is not pulled up but is floating and why its affecting my platform only.
However, surely the line
Serial.begin(SERIAL_BAUD);
should do this. You would never want the RX floating. Isn’t that asking for trouble.
I’m sure I’ve got this all wrong.
So far its been running for 20 minutes. Without the pull line it would only run for seconds, occasionally a minute. I’ve loaded the version without the pull up and this still fails so at least its consistant/repeatable.
Remember, I’ve no knowledge of your application. All I know is what you’ve posted above. I can’t be expected to even attempt to derive a circuit diagram from those photos, so I can’t see how you are connecting the RFM69Pi and to what.
That said, you’re coming round to agreeing that the problem is pickup, due either to the properties of the materials you are using or the layout of your circuit.
I agree that a high impedance floating input is asking for trouble - it’s a well-known problem, which is why I suggest pulling the line relatively weakly (so as not to interfere with the intended operation) to one or the other supply rail.
You also write
and that indicates to me that you should revisit the grounding system you have, that is, ensure that the ground connections are of sufficient cross-section to minimise volt drops and are made back to a common point where the power enters; so that all points that should be at ground potential remain as close to ground as it is possible to achieve, bearing in mind the currents those conductors will be carrying.
I’ve uploaded two more pictures, one includes a little drawing (block diagram) of my setup. The board simply contains connectors, a resister for the DS18B20, a 12v to 3.6v (3.6 needed to flip the 5v relays so saves on a 5v rail) voltage regulator board. The processor is the RFM69Pi (RFM69Pi 433Mhz Raspberry Pi Base Station Transceiver - Shop | OpenEnergyMonitor). The connector on this is green and is used to connect to the pi. I have soldered another connector to the board to access all the pins. In my case the green connector is left unconnected.
I’m now pretty sure the issue is the RX (d0) not pulled up in software and not my boards. While the design of my board may not be the best I’m not sure any faults would be that serious.
The board uses a hacked version of the RFM69Pi software that comes with this product. I’ve downloaded this from github and amended it to do what I need.
I would have thought the serial line library used would have pulled this up to prevent noise on the data line. It must set the d0,d1 to input/output. After it has been pulled up the serial line still works so I would have thought it was safer to include this line. This may also affect the emonth2 as this does not seem to have a pull up resistor attached to d0 from what I can see on the wiki and I can’t see this done in software either.
I have now amended my software to count the characters read on the serial line and send this in the packet. Without the pull up I was seeing thousands for characters being read which is not unexpected in my case. With the software pull up I see none. I will try the character count on the emonth2 to see if this has a similar issue. Even a few characters a week could be trouble. I have been using one of these for a number of years and I’m sure it has worked faultlessly but if it came close to some electrical noise could it be affected?
