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.
Sorry 'bout that, Brian.
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.
Next stage, I have now powered the PiZero, with a WiFi dongle attached, from the emonTX 3.3V output.
Seems perfectly stable and should be fine looking at the specs.
You may wonder why I’m doing this.
- It is mostly a proof of concept
- I’ve become less convinced over time with the ESP8266 devices. My experience of the Wi-Fi has been poor.
- This runs a standard emonhub so if there are issues at the receiving end and you are using the HTTP interface, it buffers the data.
- Cost. A PiZeroW is less than a tenner. Yes you need an SD Card, headers and wire (or jumpers).
The power should be to the 3.3V not 5V as seen in the photo.
The power should be to the 5V not 3.3V as seen in the photo.
@TrystanLea can I upload a bin file to the emonTX directly from the Pi? I don’t think I’d try and compile the file though .
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.
Is the 6 pin header different to the FTDI?
That proves the robustness of the Pi design - it survived 5V onto the 3.3V input (somehow). Moved it now.
OK, the 3 × 2 pin header. I’ve changed it. I think it’s for Atmel’s programmer.
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.
Running emonhub as well or just emonCMS?
Good to know.
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!
Could you help to make sure I don’t make a complete horlicks of it please?
With it wired like this, Can I use
minicom to monitor the output (presumably with emonhub stopped)?
Should the reset button still work when connected like this?
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.
Ha! famous last words!!
I just recalled that the emonTx breakout pins are (were?) labelled the wrong way round, but you should be already aware of that if you have been getting serial output ok. Easy one to get caught out by if not paying attention and IO can get damaged if both ends are trying to write via the same pin. You should connect Tx to Tx and Rx to Rx (when using an emonTx), some may say this is “easier” but it is actually the opposite to standard practice as you may know.