Flashing a Single LED to show ADC result.

Flashing a Single LED to show ADC result.
Posted by djsb on 14 Mar, 2024 16:26
Does anyone use a method of flashing an LED to show a 10 bit ADC result (PIC16F819). Imagine that this was the ONLY way to make this result visible. What would you use apart from morse code which immediately comes to mind? I'm aware that the flashing of a single LED to show diagnostic trouble codes is used on motorcycles. What else is used? Thanks.

#1 Reply
Posted by martinribelotta on 14 Mar, 2024 17:27
Well, in my university days I did a project where the LED blinked with a Morse code quite fast but with a cell phone camera and a program made in openCV it decoded messages as if it were a UART (extremely slow).

I've never really had a chance to apply it to anything useful, but there is a way... just section the image with some image processing tool and measure the on and off times, decode the ascii code and display it on the screen.

#2 Reply
Posted by snarkysparky on 14 Mar, 2024 17:31
Well ya set the LED up to be on for 500 ms if a bit is high and 200 ms if a bit is low. With 1 second off between bits.
Test all the bits from most significant to least significant setting the appropriate ON time.

Scale the times for what you can comfortable jot down while watching.

#3 Reply
Posted by peter-h on 15 Mar, 2024 09:35
If you want it machine-readable, there are many options for encoding 10 bits.

Many years ago I designed a fibre modem, up to 4km multimode fibre, which did 1 pulse for a rising edge and 2 pulses for a falling edge. This was done to make the LED last longer (a real issue btw in that application).

#4 Reply
Posted by ozcar on 15 Mar, 2024 20:50
Why complicate things by using morse* or some DIY coding scheme?

What's wrong with just bit-banging normal serial communication in "softwareSerial" fashion? If connecting to the pin that drives the LED is not allowed by the rules of engagement, a UART or something like a serial-USB converter could still be used as the receiver by adding something to spy on the LED without too much effort.

* I'll admit to using morse code for output from a microcontroller once, but that was driving a buzzer/beeper not a LED. To adapt an old phrase, "Morse is to be heard and not seen".

#5 Reply
Posted by DavidAlfa on 15 Mar, 2024 20:54
Why?

#6 Reply
Posted by fourfathom on 15 Mar, 2024 22:36
Quote from: DavidAlfa on 15 Mar, 2024 20:54
Why?
I've done this before, with a serial software UART (as in ozcar's post above) driving a LED. I used a phototransistor circuit as a receiver. This was for non-contact debugging where the existing hardware made this the simplest solution. Anyway, I could use standard printf formatting for my debug info.

#7 Reply
Posted by Kim Christensen on 15 Mar, 2024 23:25
If you have one of those TC1 component testers, or other device that reads TV remote codes, you could output the ADC data as IR remote codes.

#8 Reply
Posted by Veketti on 16 Mar, 2024 07:51
I made few years back to the car I had at that time (Subaru Forester XT), where I installed oil catch can, discreet led to cabin to show the pressure rise in the breather system. As the winter can be challenging in Finland, I didn't want the system to freeze, block the breather, blow oil out and destroy the engine. So to the breather hose, I added VDO pressure sensor then PIC ADC to read the voltage and led to cabin to show the pressure. One hertz blink was 0.1bar, 2Hz was 0.2bar etc. Then after a delay, how many blinks told the pressure eg. three blinks equal to 0.3bar. Then measured the force to pull the dipstick out and knowing the diameter of the tube, calculated the pressure to lift it off and with that pressure made the led continuously on.

#9 Reply
Posted by cv007 on 16 Mar, 2024 20:07
Quote
What would you use apart from morse code which immediately comes to mind?
Why 'encode' the data into a 'language' only few could read?

You can simply blink out the decimal number, which anyone can read.

I use an Led class which is a derived class from a pin class, which has additional methods to blink when needed.

Code: [Select]
//============================================================================== class Led : public PinOutput //============================================================================== { static constexpr auto blinkDly_{ 200_ms }; static constexpr auto digitDly_{ blinkDly_*5 }; public: Led (MCU::PIN pin, INVERT invert = HIGHISON) : PinOutput( pin, invert ) { } //caller in charge of any delays before/after blink/code, and led initial state //led will be in same state as when called auto blinkN (u8 n, u16 dlyms) { u16 nn = n*2; //will toggle, so x2 while( nn-- ){ toggle(); Rtc::delay( dlyms ); } } auto blinkDecimal (u16 v) //0-65535 { bool lz = true; //start in leading 0 mode u16 dv = 10000; //10000,1000,100,10 while( v >= 10 ){ u8 v1 = v/dv; v -= v1*dv; dv/=10; if( v1 == 0 and lz ) continue; //skip leading 0's lz = false; //not a leading 0 anymore blinkN(v1 ? v1 : 10, blinkDly_); //0->10 Rtc::delay( digitDly_ ); } blinkN(v ? v : 10, blinkDly_); //last digit always shown } }; //.............................................................................
usage-
Code: [Select]
#include "attiny3217_24.hpp" #include "Led.hpp" #include "Adc.hpp" Rtc rtc; Led led { MCU::PA3, PinOutput::LOWISON }; int main () { //blink temperature in degrees F, every 10 seconds while( true ){ led.blinkDecimal( Adc::readTempF() ); rtc.delay( 10_sec ); }
Obviously I run into a problem when temperature returns a negative number, but is just a simple example that could actually have a real world use (and would then deal with negative in some way).

I have used this method to blink out bluetooth api error codes in an nrf52 board which had no debugging abilities and only the led's on board were guiding me to success via error codes (not an ideal way to get introduced to an mcu and bluetooth, but it worked).

#10 Reply
Posted by DavidAlfa on 16 Mar, 2024 21:27
Still don't get why the effort, this is not a real thing, he's just wondering.
The answer is "yes it can be done", nothing else.

#11 Reply
Posted by SiliconWizard on 16 Mar, 2024 22:00
Quote from: fourfathom on 15 Mar, 2024 22:36
Quote from: DavidAlfa on 15 Mar, 2024 20:54
Why?
I've done this before, with a serial software UART (as in ozcar's post above) driving a LED. I used a phototransistor circuit as a receiver. This was for non-contact debugging where the existing hardware made this the simplest solution. Anyway, I could use standard printf formatting for my debug info.

Yes, but in that case that could be useful, but the OP says "show", which we can only infer as meaning being readable by a human with just their eyes. Or so I guess.
Not sure what the point is, but any kind of encoding could be used. Maybe just flashing the decimal digits of the number in sequence by the corresponding number of pulses, at a reasonable rate with some gap between digits, and a larger gap between each full encoded sample, would be the "easiest" to read as long as you can count to 10 (10 pulses coding 0, for instance) and memorize 4 digits, and wouldn't require learning morse code. For fewer LED pulses to deal with, you could encode binary instead of decimal (but that'll be 10 bits to memorize and then convert to decimal), with 1 pulse for 0, 2 pulses for 1 (or conversely), with a small gap between bits. Probably still easier than learning morse code, unless you already master it of course.

#12 Reply
Posted by amyk on 17 Mar, 2024 05:49
Like others have mentioned, I'd use it like a UART --- but operating at human speeds, e.g. 1 baud, then anyone with a stopwatch or a second hand can just read the bits.

#13 Reply
Posted by cv007 on 18 Mar, 2024 04:09
Quote
e.g. 1 baud, then anyone with a stopwatch or a second hand can just read the bits.
Include start or stop bit? data length as many data bits as needed? bit order? while looking at the stopwatch and looking at the led, you also have to write down the 'bit values' and decode them. I'll bet you wouldn't do this.

Here's a video of my previous post, displaying temperature-
https://photos.app.goo.gl/SDRRb3Ki9Ddivf2QA
somehow I doubt anyone will have a hard time decoding the temperature value, without any instructions.

Quote
flashing an LED to show a 10 bit ADC result
The value will have a higher meaning than a simple adc value, so you would be displaying 'something' but you wouldn't call it an adc value, and most likely not use as-is. It will be a voltage, temperature, position, etc., and that will be the value you want to communicate.

Quote
I'm aware that the flashing of a single LED to show diagnostic trouble codes is used on motorcycles. What else is used?
Without wires/wireless and no display of any kind, there is a good reason blinking an led is the solution- its self contained to the code producing device and is a 10 cent part. Beeping the horn, flashing the headlight, cranking the starter, flashing the brake light, etc., are all worse solutions for multiple reasons.

Its not a big jump from single led to single 7 segment led, or multiple led's, but it could be that anything other than a single led is simply more complex than what is needed. It could also be reading from 10' away is easy with a single led, and difficult/not possible to read with multiple led/7seg led(s) at that distance if distance is a factor (that could also apply to lcd or any display).

Wireless is cheap enough now, and is what I do for temperature around the home (broadcast via ble, read on smartphone with no special app needed), but blinking an led to communicate temperature outside 10 feet away is not a bad minimal solution, unless you plan on putting it in direct sunlight. Blink codes via led is also a good solution to communicate problems in an mcu.

#14 Reply
Posted by Psi on 18 Mar, 2024 04:35
If you really want to use an LED you can flash a number of times for each decimal digit. Like how some old digital watches would beep the time.
312 would be 3 flashes, pause, 1 flash, pause, 2 flashes. etc.. With a longer pause before repeating.

It's very readable for a human looking at the LED as long as you know that's what it's trying to do.

#15 Reply
Posted by AVI-crak on 18 Mar, 2024 08:42
Show the result of a voltage measurement???
I think you need a quick way to show the result. So fast that a quick glance is enough.
In this case you need to limit the range of voltages when something interesting happens. For example, a 12v car battery voltage indication. The critical voltage is 9V and below, as well as 14.8V and above - the state when it is necessary to blink the LED to attract attention. The range of normal state to display the brightness level, it will be enough.
If you use color LED WS2812 2020 - the indication will be more informative and natural.

#16 Reply
Posted by mikeselectricstuff on 18 Mar, 2024 09:24
Quote from: peter-h on 15 Mar, 2024 09:35
If you want it machine-readable, there are many options for encoding 10 bits.

Many years ago I designed a fibre modem, up to 4km multimode fibre, which did 1 pulse for a rising edge and 2 pulses for a falling edge. This was done to make the LED last longer (a real issue btw in that application).
IrDa solved that, more efficiently - UART frame. with presence or absence of a pulse indicating 0 or 1

#17 Reply
Posted by mikeselectricstuff on 18 Mar, 2024 09:26
Quote from: amyk on 17 Mar, 2024 05:49
Like others have mentioned, I'd use it like a UART --- but operating at human speeds, e.g. 1 baud, then anyone with a stopwatch or a second hand can just read the bits.
for human-readable you want it to be self-clocking, not depending on separate timing - long/short flashes, with a long gap for framing

#18 Reply
Posted by BradC on 18 Mar, 2024 09:37
Quote from: Psi on 18 Mar, 2024 04:35
If you really want to use an LED you can flash a number of times for each decimal digit. Like how some old digital watches would beep the time.
312 would be 3 flashes, pause, 1 flash, pause, 2 flashes. etc.. With a longer pause before repeating.

I use this to get data from the fuel burning heater in my car. I have a 4 button remote I use to talk to it and about 20 diagnostic/operational commands. It replies by blinking a bright white LED hidden in the radiator grille so I can see through the window in the house.

Simple decimal, although 10 blinks for zero kinda reminds me of the old mechanical decadic phone diallers.

#19 Reply
Posted by mikeselectricstuff on 18 Mar, 2024 10:05
Do you really need all 10 bits?

#20 Reply
Posted by cosmicray on 18 Mar, 2024 11:09
Does it need to be a single LED emitter, or could you use one of those RGB devices, where the different colors/combinations have different meanings. Flashing them (same color or different color combinations) could greatly expand the transfer of information.

#21 Reply
Posted by Doctorandus_P on 18 Mar, 2024 13:51
You can also use PWM and the brightness of the LED will vary. But eyes are very non-lineair and judging it by eye will be at a very coarse resolution.

#22 Reply
Posted by Geoff-AU on 19 Mar, 2024 10:33
Quote from: SiliconWizard on 16 Mar, 2024 22:00
but the OP says "show", which we can only infer as meaning being readable by a human with just their eyes.

That's how I inferred it, but plenty of people went straight to machine ~~learning~~ reading.

Maybe OP can come back and clarify before we've shouted all possible permutations into the void.

#23 Reply
Posted by cncjerry on 24 Mar, 2024 16:54
Quote from: Psi on 18 Mar, 2024 04:35
If you really want to use an LED you can flash a number of times for each decimal digit. Like how some old digital watches would beep the time.
312 would be 3 flashes, pause, 1 flash, pause, 2 flashes. etc.. With a longer pause before repeating.

It's very readable for a human looking at the LED as long as you know that's what it's trying to do.

This is used for furnace controllers i have seen and you can cut it in half by using short pulses and shorter pulses.

#24 Reply
Posted by mark03 on 24 Mar, 2024 17:52
Fun fact: This technique has been used to dump firmware for reverse-engineering purposes. IIRC it was a key step in the development of the CHDK alternative firmware for Canon cameras.

The "best" way depends how much time you want to spend and whether or not it should be human-readable. Simple UART is probably the most obvious choice.

But optical LAN researchers have figured out the best approach for high-speed data over LEDs. They use pulse-position modulation (PPM). Imagine subdividing each of your time slices into 2^N slots; turn the LED on for just one of those slots to encode an N-bit number. If you are average-power constrained but not peak-power constrained (obviously not true forever, but up to a point...), you can increase N and proportionally increase the LED brightness to keep the average power constant. N=2 is just Manchester. As N grows, so does the energy per bit Eb, because you are using the same energy per time slice but sending more bits. N0 is constant so you can increase your Eb/N0 and thus your throughput without bound until (1) you hit a peak-power constraint, or (2) you reach a switching speed limit. Pretty cool stuff.

This was all next-gen IrDA stuff which never got deployed commercially, presumably because WiFi was just too good and cheap, without the drawbacks [blockages] of optical.