Flashing a Single LED to show ADC result.

[djsb]

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.

[martinribelotta]

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.

[snarkysparky]

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.

[peter-h]

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).

[ozcar]

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".

[DavidAlfa]

Why?

[fourfathom]

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.

[Kim Christensen]

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.

[Veketti]

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.

[cv007]

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).

[DavidAlfa]

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.

[SiliconWizard]

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.

[amyk]

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.

[cv007]

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.

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.

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.

[Psi]

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.

[AVI-crak]

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.

[mikeselectricstuff]

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

[mikeselectricstuff]

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

[BradC]

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.

[mikeselectricstuff]

Do you really need all 10 bits?

[cosmicray]

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.

[Doctorandus_P]

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.

[Geoff-AU]

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.

[cncjerry]

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.

[mark03]

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.