Raspberry Pi version

[CathalOConnorRH]

I've bought the kit and have just received it but I have a question on the Raspberry Pi. Would this work on the raspberry pi 1 for just monitoring the power values and grafana etc were hosted on another server ? If not, Is there a minimum ram spec you think is needed for the raspberry pi?

Thanks.

[David00]

I wouldn't recommend using the Pi 1, or Pi 2, or the original Pi 3. I haven't tested any of those, but my recommendation is based off of my experience using the Pi 3B+ and 4B. The 3B+ seems to be the minimum threshold for performance. The biggest concern is the CPU. It's quite CPU intensive because it's performing tens and tens of thousands of the calculations on the raw data per second. I'd imagine the database and Grafana dashboard only add a small bit of overhead when compared to the actual sensing and calculating of the raw data.

There's no harm in trying it on your Pi 1, though. I'd suggest running the software in debug mode so that it will generate a plot of the raw data. Debug mode doesn't require influxDB to be running. In the plot, you can see the actual waveform of the data. Just plug in the 9V AC voltage input, start the debug mode to generate the plot, and then view the plot (all documented here).

The voltage wave should look like a smooth sine wave and the more peaks you can count, the better. The plot should have around 30 peaks for it to be considered fast enough for this project. Also, the spacing between the peaks should be equidistant. This is a visual depiction of how regularly the Pi is able to execute the code and sample the data. Irregular sampling intervals (as indicated by varying amounts of space between peaks in your plot) would suggest the Pi can't keep up with the demand.

My recommendation is to use the Pi 4B 2GB version.

[CathalOConnorRH]

Thanks for the detailed response. I'll order a Pi4 but I'll give the Pi 1 a go and see if it would work out of curiosity. I'll update this issue once I have an answer either way.

[David00]

No problem! Your question actually prompted me to look into something I've been wanting to do since I began this project, which I think will actually be useful for you and your Pi 1. It might even allow this project to work on the Pi Zero, but I don't want to get ahead of myself.

Yesterday I began converting the project to Cython. Basically, it allows me to offload all of the heavy calculations to C, which will run as a compiled extension of Python and provide a huge speed improvement. In the amount of work I did yesterday, I'm already seeing upwards of 50% improvements in speed. I still have more optimizations to make, but it is looking promising for allowing lower-powered/older devices to run at least the sensory and calculation part of the project.

I have a busy weekend coming up so I don't think I'll have anything to share until sometime mid next week. I'll add a new branch to the repo with this new version of the project then with some instructions on how to get it.

[kobuki]

@David00, great work on this project! I've just browsed through the huge OEM community thread where you detail every step of your work. I was thinking about making something similar this year - in an attempt to bring all calculations and bookkeeping of sampled data to the Pi, using pure Python tools and MCP3208 instead of the MCP3008. You kind of already finished something like that, nice! This alone shows that this is indeed possible.

Now the actual question, somewhat related to the above (If I should ask in a separate issue or bring the question to the OEM forum, please just say so). What is the total sample rate and the per-channel sample rate you can achieve with your setup - Python 3 and RPi 4B?

Also, instead of Cython, wouldn't it be more beneficial to use NumPy and/or SciPy to handle the heavy calculations? These great libraries already have native code bound to them in the package, for fully utilizing the underlying CPU. (Actually, with my planned project, I was to use them for the same purpose.)

[David00]

@kobuki, thanks!! While the MCP3208 has a higher resolution, it also has a slower maximum sampling rate. You may be able to use it as a drop-in replacement for the MCP3008 but you'll have to reduce the SPI clock speed. The datasheet for the 3208 lists a max clock speed of 1.0MHz at 2.7V, whereas the 3008's minimum at 2.7V is 1.35MHz. Since the chip is running at 3.3V, the clock speeds can be run a bit higher, but I doubt you'll be able to run the 3208 at the same 1.75MHz clock that I'm running the 3008, and this will have a hit on the sampling rate.

I do want to create a separate issue to track the benchmarks, optimization ideas, and more. I like your idea of using NumPy instead of Cython - it would be interesting to compare the two. I've created a separate issue for this subject in which I'd like to move this optimization conversation to: #17. Would you (kobuki) like to assist with a NumPy optimized fork of the project?

As for the original issue, I'm curious to see if @CathalOConnorRH tested the current version of the project out on the original Pi 1, but the current recommendation still stands at the Pi 3B or newer. Eventually, this recommendation will change when optimizations are finalized.

[kobuki]

I've already ordered the PCBs from PCBWay, they should be here in a few weeks per usual. My hands are full with my job nowadays but I'll help with optimizations where I can. It's likely that using a lib with native code support like NumPy will require some major rework in how things are processed. I'll outline my ideas in the new thread.

WRT clock and ADC resolution. The MCP3208 is capable of 100 kSPS at 12 bits. In the other thread you mentioned an average sampling rate of 4-4.5 kSPS, and thus I think the limiting factor is not the chip but Python itself.

[CathalOConnorRH]

@David00 I'll be testing the pi tomorrow all going well. I have the circuit built and should fine some time tomorrow to install and test. Will let you know how it goes.

[CathalOConnorRH]

Hi @David00 I've just gotten the pi disconnect and the header size is different on the older Pi. I'll just order a new one and use that instead.

[DuduNord]

Hello. Just for those who can be interested, I tried to install everything on a Pi0W. But the docker images seem not compliant with a RPI0W. It works well on a RPI4. In fact the docker try to reset/reboot both Grafana/Influx continuously with an errot 139. Some posts say that the used docker images are just not compliant with the RPI0 ARM architecture. They have anyway proposed another way to install Influx (did not check for Grafana). So it should be possible with more investigation. May be easier just to use a PI3. I also tried with a OrangePI One+ (1GB ram/H6 core) but the installation was creating some issue : docker/grafana/Influx worked well, but 3 installations from "requirements.txt" did make errors : prettytable/plotly/spidev. And i was not sure if the hardware SPI would work. Again should be easy to translate by searching around as the GPIO connector is compatible with the RPI.