Connect the grounds from each device to a common point.
e.g. connect the negative leads of all your power supplies to that common point.
Bonding the various components to a common point ensures all of the signals are referenced to the same “ground.” That can help keep serial datacomm (as well as other electronic devices) from acting strange.
Grounding, or earthing, is for safety. Given the low voltages involved in an emonTx and RaPi,
there’s not much of a safety hazard. Nevertheless, it’s not a bad idea to connect the common point
to earth to keep static charge buildup to a minimum.
But practically, how would you do that? All 3 power supplies are plugged into the same power strip and the ground pins are connected. I cannot see that I can do any more.
What you must not do is ground one side of the a.c adapter if you’re using an emonTx V2, because that’s connected to the 1.65 V rail, though you can use one a.c. adapter with many emonTx V2’s (but not a mix of V2 & V3).
For all the rest (emonTx V3 & emonPi), the barrel of the a.c. connector is GND to the p.c.b., hence to any other device that’s connected via the RJ 45, the FTDI connector or the screw terminals.
I should have been a bit more specific with my description.
When I mentioned connecting the negative side of the power supplies together,
I took it you’d understand I was referring to the DC side of the PSUs.
Providing you have connected both the rx and tx lines of the serial comms, you can simply add a chip reset wire and use avrdude with rpi-avrdude as described in the rfm2pi wikis. I used to do it all the time at one stage.
Are you saying you are powering the zero from the ac:ac adapter via the emontx? I’ve never tried that as I expected the zero to significantly deform the voltage waveform at the very least.
IMO in all aspects the zero is superior to the esp method and factoring in the price and the sdcard, it’s still a winner. Even more so when hosting emoncms on it too (i know you prefer to seperate them though) for an all in one solution like an emonpi with 4cts for considerably less money.
I can see a d.c. power supply cable in Brian’s photo. With a minimum draw of 80 mA, the Pi Zero won’t deform the voltage, it will collapse it completely.
That makes more sense but I was thrown by the fact the photo shows a wire going from the ftdi to the 3v3 pin of the rpi GPIO, I understood the ftdi to be connected to the 5v rail If the emontx was running off 5v the RPi should be seeing 5v on the 3v3 pin (not healthy) so I wondered if 3.3v might be output on the 5v pin of the ftdi when only ac powered (I’ve never tested)? Or are the later emonTx’s different? Or is the 3.3v not being drawn from the ftdi, ie the pic isn’t correct/current?
PS I’ve also corrected my previous post to include adding the chip reset line.
Doh! @pb66 I completely missed your post on using the Pi and emonTX - saved a load of time. Really irritating; I obviously did not look properly.
No I have DC and AC supplies connected to the emonTX - I would not expect it to work with just AC so didn’t try.
Ok, I have switched it and it seems fine. It was unclear to me if as an input it would take 5V that would be stepped down but as internally it was 3.3V if as an output it would be 3.3V. I’ve switched it now and still seems happy.
Ok I’ll have a look. I can see that connection on your post on the thread I missed . Is there anything else to look for when trying this? I suspect this was written quite a while back and things in the RPi world have moved on.
I note it is using rpi-serial-console - is this still the best way?
I would be concerned that the PiZero would not really have enough grunt. I might give it a go.
The 5 V USB connector feeds the screw terminals, the RJ45 connector and the FTDI; and the MCP1702 regulator to provide the 3.3 V supply. The '1702 in turn feeds the processor, radio, the 3 × 2 pin header, the RJ45 and the screw terminals. The MCP1702 is rated at 250 mA, the thermal resistance looks to be about 150°C/W, so it should not be limited by power dissipation and temperature.
The a.c. input supplies the MCP1754 regulator to provide only the 3.3 V via the jumper link. That’s the supply that can only support a couple of temperature sensors - by design.
So if your Pi is taking the 5 V from the FTDI connector, it’s coming straight off the USB input socket.
Pi Zeros work fine - my local emoncms has been on a v1.3 one for a long time. After all there’s a lot of processor there doing very little most of the time.
By way of an update, I bought some dupont connectors, a crimping tool and made up a cable. I had the case lying around and the Pi already had the header soldered on.
Currently running a full emonScript install.
The improvement would be to use right-angle headers and this case - it would be really neat then!
Yes you can, although I (and PIO) prefer to use miniterm, it used to be included in all but the most recent versions of the python(3)-serial package.
This will work ok for when the sketch is running, obviously there should be command line output whilst uploading without need for any serial term, in fact you must ensure that nothing is using the serial port when trying to upload.
TBH it will either successfully upload or it won’t, there are no easy ways to mess it up, assuming the correct sketch is compiled of course.
The gist of it is to use the rfm2pi wiki for rough guidance and a command line string template, changing the port address, hex location and maybe the upload baud too (unrelated to the usual baud set in the sketch) offhand I cannot recall the correct upload baud without confirming.
If you have difficulties post the issue and I’l try to help out, but without running through a similar upload to remind myself, I’m not sure what other advice to offer.
.
. Is there anything else to look for when trying this? I suspect this was written quite a while back and things in the RPi world have moved on.
