Any raspberry pi-ists?

[RaceDiagnostics]

Your description oversimplifies the complexities of getting a system working though if your not an electronics engineer with software capability.

It reminded me of how to build a nuclear power station.

1) get some enriched uranium off the dark net.
2) get some control rods from banggood.
3) connect them up to your boiler and turbine.
4) connect up to the grid.

Bob's your uncle.

 

[bigegg]

Your description oversimplifies the complexities of getting a system working though if your not an electronics engineer with software capability.

It reminded me of how to build a nuclear power station.

1) get some enriched uranium off the dark net.
2) get some control rods from banggood.
3) connect them up to your boiler and turbine.
4) connect up to the grid.

Bob's your uncle.

TBF to me (I'm assuming the above is directed at me):

I have connected a 12V temperature sensor to an arduino which was installed in a car - I used an "amplifier" circuit to convert the 12v analog range to 5v. I would give you a link to the module I used, but it was so long ago its not on my ebay history.

TLDR: it is MUCH easier (and cheaper) than it used to be - certainly within the capabilities of (my perceived view of) most of the people on here.

It was *literally* a little PCB with 3 inputs, and three outputs - VCCin, Signal, GND, VCCout, signal, GND.
connect car battery to VCCin, raspPi 5V to VCCout
signal IN was from (14.8V)12V to zero, and it gave signal out 5V to zero.

Thinking about it now, I'd run the output through a optoIsolator - I didnt at the time, but I'm not sure if the module already had one?

<edit: I've had a google, and I can't find the specifc forum/website with instructions, but several more recent lnks imply that a voltage divider using two resistors would convert a 0-12V analog signal to 0-5V? I used an "amplifier" modul;e>

 

[Fastdruid]

Your description oversimplifies the complexities of getting a system working though if your not an electronics engineer with software capability.

It reminded me of how to build a nuclear power station.

1) get some enriched uranium off the dark net.
2) get some control rods from banggood.
3) connect them up to your boiler and turbine.
4) connect up to the grid.

Bob's your uncle.

I mean technically you can do it with mere natural uranium... Something like 4.9 tonnes of Uranium, 41 tonnes of Uranium dioxide and 330 tonnes of ultra pure graphite should do the trick. Some cadmium sheets nailed to wooden strips should do as control rods...

 

[m_c]

TLDR: it is MUCH easier (and cheaper) than it used to be - certainly within the capabilities of (my perceived view of) most of the people on here.

The issue is, interfacing to a sensor is only one part of the puzzle.
That can be done using various different sensor types.

Once you have the interfacing done, you then need to code to interpret the data.
Once you have that data, you then need to process it, and display it.
For the display, you need a suitable display. The amount of brightness required for a display in daylight is quite high, so your cheap display for £30-40 isn't likely to cut it.
You then need to code the display. Sounds simple, but graphics aren't that easy to code.
Once you have all that, you then need to power everything. Automotive electrical environments contain very noisy power, so you need a suitable automotive rated power supply.
Then finally you need to package it all up into something reasonable looking.

None of that is insurmountable, but as someone who's played with this kind of stuff as a hobby for years, I wouldn't describe it as easy, unless you already have a good understanding of the programming involved, especially around displays and displaying data.

 

[bigegg]

The issue is, interfacing to a sensor is only one part of the puzzle.
That can be done using various different sensor types.

Once you have the interfacing done, you then need to code to interpret the data.
Once you have that data, you then need to process it, and display it.
For the display, you need a suitable display. The amount of brightness required for a display in daylight is quite high, so your cheap display for £30-40 isn't likely to cut it.
You then need to code the display. Sounds simple, but graphics aren't that easy to code.
Once you have all that, you then need to power everything. Automotive electrical environments contain very noisy power, so you need a suitable automotive rated power supply.
Then finally you need to package it all up into something reasonable looking.

None of that is insurmountable, but as someone who's played with this kind of stuff as a hobby for years, I wouldn't describe it as easy, unless you already have a good understanding of the programming involved, especially around displays and displaying data.

That's where it's actually easy, IMO.
"Trivial" in fact:

I mentioned earlier about "home assistant' (which is an *massively* supported open source project.

The sensor data is easily interfaced/integrated to it once it's been read as a 0-5v analogue signal, or via a serial connection.
Then the work is already done - it can be output to a webpage (built in), or a LCD display connected to a microcontroller (£5 ESP32) without any great effort.

At the moment, I have a raspPi running home assistant which reads sensors from 6 different MCUs, and outputs details to two different LCDs, two tablets, a mobile phone, and a PC.

and it is *easy* (for a given value of "easy")

Theres no "programming" (as such) -
it's merely "configure output.
Write output.
Update output
Repeat"

As an 70s/80s child - it is *scary* how much technology has improved and become integrated.
Stuff that I thought was impossible is now mundane.

In a vehicle, a cheap android tablet running any browser can be used as an interface.
I have a raspPi with a 3" touchscreen running autoPi at the moment - there's no issues (so far) with "brightness" - it's as easy to see as the early 2000s built in satnav it replaced


TLDR: "home assistant" will output sensor data as a webpage on any connected browser

 

[bigegg]

Example of user interface

The sensors are all connected via individual "slave" processors (esp8266)s - once the main system is told where to find them (basically type in the ISP) everything else is automatic.

 

[bigegg]

 

[bigegg]

View attachment 336168

Basically:
Click "edit"
Choose data source.
Choose a "card" (which is how you want the data displayed - graph, gauge, text etc).

That's it.

And it's available on any browser that's connected to the server


<edit:
"code" I wrote to display thermostat details on a LCD connected to a esp32 "slave" system

display:
- platform: pcd8544
reset_pin: GPIO4 #d2
cs_pin: GPIO5 #d1
dc_pin: GPIO12 #d6
contrast: 0x7f
lambda: |-
it.strftime(0, 0, id(utahB_12), "%d-%m-%Y ", id(HAtime).now());
it.strftime(0, 10, id(utahB_12), "%H:%M", id(HAtime).now());
it.printf(0, 20, id(utahB_12), "%.1f°C (%.0f°C)", id(lr_temp).state, id(thermo).state);
std::string val = id(boiler_switch).state;

it.printf(0, 30, id(utahB_14), "heating: s", val.c_str());

to break it down: its a config file that tells home assistant what LCD is connected. which pins its connected to, and then four lines of text, including variables.

It took me 10 minutes, if that, to get it working. - and most of that was getting my head around C++ syntax. ( the "lambda" section. for whatever reason, c++ is called "lambda" code in HA)



Produces this.

 

[m_c]

That's where it's actually easy, IMO.
"Trivial" in fact:

Is this bit also "Trivial"?

I’d like to just have one unit that can play tunes, do nav and display temps and pressures for oil, air and water

 

[Dev]

Is this bit also "Trivial"?

On a raspberry pi? yes.

edit: you’re right about the noisy power though which is why I’d look at an android based head unit and apps personally.

 

[m_c]

On a raspberry pi? yes.

But via a screen that is easy to use with minimal driver interaction needed?

As I've been getting at, all the individual bits are relatively easy. It's the combining things into a suitable user friendly package which is the hard part.

 

[Dev]

But via a screen that is easy to use with minimal driver interaction needed?

As I've been getting at, all the individual bits are relatively easy. It's the combining things into a suitable user friendly package which is the hard part.

Its a lot of work for sure, but so are a lot of things. The challenge is what makes it rewarding if that’s your jam.

 

[JMS1972]

I mean technically you can do it with mere natural uranium... Something like 4.9 tonnes of Uranium, 41 tonnes of Uranium dioxide and 330 tonnes of ultra pure graphite should do the trick. Some cadmium sheets nailed to wooden strips should do as control rods...

Pretty sure that's how they used to do it before Health and Safety stuck their oar in!


This is a joke @Parm step away from the machete... Eek

 

[bigegg]

But via a screen that is easy to use with minimal driver interaction needed?

As I've been getting at, all the individual bits are relatively easy. It's the combining things into a suitable user friendly package which is the hard part.

A PI is basically a desktop Linux computer with a touchscreen - one window would have autoPi controlling/casting satnav from your phone. Another window is a browser connected to HomeAssistant serving the sensor data.
HA can also serve media directly or from other media sources like internet radio, or YouTube, or Spotify.

Maybe "trivial" is over-exageration, but I'd certainly say its "easy" - _especially_ the display part,

This is my latest one, mid-installation.


The keyboard to the right is a Bluetooth mini with a built in mouse controller, but the pi is fully controllable via the touchscreen, so it usually just lives in the glovebox until/if I have any typing to do.

Running on a rasp-pi 3b, with a "waveshare" 7in touchscreen.
The Lexus has OBD2, so the sensor side "back end" was easy as it just connects via BT and is displayed on an app - but it wouldn't have been much more effort to run a suitably converted sensor signal to a GPIO pin on the pi (or to another smaller processor to pass on via BT or WiFi.)

 

[Wedg1e]

I recently put together a microcontroller based on a Pi4B, on advice from my son-in-law who's well versed in such matters.
We needed to read a simple resistive potentiometer (height of a scissor table) and he said the Pi could not accept that directly as an analogue input, so we used a 'Maker Uno' which is a £6 Arduino copy that connects to the Pi by USB.
The 'human-machine interface' was taken care of by a 10.1" touchscreen which uses the HDMI out from the Pi and another USB input to the Pi for the touch function.
With a couple of hours' coding work (largely cribbed from the internet) the bulk of the job was done (it runs an industrial x-ray system); fine-tuning based on client feedback is accomplished by me taking a wireless router to the client site and then SIL logs-in to the Pi and makes changes while I wait
Hardly worth my effort learning any of the coding side, I'll stick to building the control panel.

 

[Wedg1e]

I recently put together a microcontroller based on a Pi4B, on advice from my son-in-law who's well versed in such matters.
We needed to read a simple resistive potentiometer (height of a scissor table) and he said the Pi could not accept that directly as an analogue input, so we used a 'Maker Uno' which is a £6 Arduino copy that connects to the Pi by USB.
The 'human-machine interface' was taken care of by a 10.1" touchscreen which uses the HDMI out from the Pi and another USB input to the Pi for the touch function.
With a couple of hours' coding work (largely cribbed from the internet) the bulk of the job was done (it runs an industrial x-ray system); fine-tuning based on client feedback is accomplished by me taking a wireless router to the client site and then SIL logs-in to the Pi and makes changes while I wait
Hardly worth my effort learning any of the coding side, I'll stick to building the control panel.

I should add that the 'Maker Uno' lacks the ADC resolution of a real Arduino, having only 1024 steps... but we only needed to look at a range of about 600mm so scaled the Maker accordingly which gives us 1mm positional accuracy on the scissor table sensor - more than good enough for radiography. In practice we've set up a 4mm tolerance so as long as the table ends up in that window it'll never show up on the x-rays. Scissor tables don't move at a linear speed anyway, there's a greater movement at the top and bottom of the travel for a given amount of hydraulic ram movement, so at the bottom end (table closed) it hunts a bit, but gets there in the end.

 

[bigegg]

I should add that the 'Maker Uno' lacks the ADC resolution of a real Arduino, having only 1024 steps... but we only needed to look at a range of about 600mm so scaled the Maker accordingly which gives us 1mm positional accuracy on the scissor table sensor - more than good enough for radiography. In practice we've set up a 4mm tolerance so as long as the table ends up in that window it'll never show up on the x-rays. Scissor tables don't move at a linear speed anyway, there's a greater movement at the top and bottom of the travel for a given amount of hydraulic ram movement, so at the bottom end (table closed) it hunts a bit, but gets there in the end.

10channel 32bit (4billion step) modules are around £40

High-Precision AD HAT For Raspberry Pi, ADS1263 10-Ch 32-Bit ADC

High-Precision AD HAT For Raspberry Pi, ADS1263 10-Ch 32-Bit ADC

www.waveshare.com

I'm sure bangood or AliExpress will have something cheaper, if needed.


But, I don't think it has to be *that* hi-res?

1024 steps gives 0 - 512psi in 0.5psi steps.
Or 0-100°C in 0.1°C steps.

 

[Wedg1e]

10channel 32bit (4billion step) modules are around £40

High-Precision AD HAT For Raspberry Pi, ADS1263 10-Ch 32-Bit ADC

High-Precision AD HAT For Raspberry Pi, ADS1263 10-Ch 32-Bit ADC

www.waveshare.com

I'm sure bangood or AliExpress will have something cheaper, if needed.


But, I don't think it has to be *that* hi-res?

1024 steps gives 0 - 512psi in 0.5psi steps.
Or 0-100°C in 0.1°C steps.

Well yes, as I said we got 1mm height accuracy on a hydraulic scissor table... didn't need to be any better for the application, and if it did the hydraulics would be the limiting factor, we'd have to go to some form of electric linear actuator.

 

[bigegg]

Well yes, as I said we got 1mm height accuracy on a hydraulic scissor table... didn't need to be any better for the application, and if it did the hydraulics would be the limiting factor, we'd have to go to some form of electric linear actuator.

If it needed to be more accurate, would it be better to spend on better position sensing and add some sort of PID servo control? (I have no idea, btw - "sensors and control" was a course I wanted to do with the OU, but it got cancelled before I could complete the prerequisites, then life got in the way)

<edit: just investigated, and it looks like they've finally got around to offering a replacement/equivalent course starting october - that'll give me something to do next year>

 

[Wedg1e]

If it needed to be more accurate, would it be better to spend on better position sensing and add some sort of PID servo control? (I have no idea, btw - "sensors and control" was a course I wanted to do with the OU, but it got cancelled before I could complete the prerequisites, then life got in the way)

<edit: just investigated, and it looks like they've finally got around to offering a replacement/equivalent course starting october - that'll give me something to do next year>

You're right - if it NEEDED to be more accurate we'd have done it a different way, but the system has used a scissor table since at least as far back as the 1970s - in an earlier incarnation it used a punched metal strip and phote emitter/detector, counting the pulses as the table rose and fell. That only had about 10mm resolution; the last version used the same resistive sensor we're retained with the Pi, but it was read by a translator unit that generated 4-20mA for a Siemens PLC.
We've just read it as a variable resistor producing a voltage that sweeps from 0-5V and then told the Arduino-alike which span of it we're interested in.
It does have an element of closed-loop control in that we gave it a 5 second window to hit the required value: if the table falls too far it fires up the pump to lift it, at which point it overshoots the other way, so it bleeds off fluid and lowers it, at which point it overshoots... but the 5 second window is enough to get it within range. It only really 'hunts' right at the bottom of the travel, where as I said the correlation between ram movement and scissor movement is most exaggerated.
You might think that swapping the ram for an electric actuator would fix it, but if you've ever tried it you'll know it's not that simple...