Вставка
- Опубліковано 18 сер 2022
- You've built a project. It's working. Hurrah. Now it's suddenly stopped working. What has gone wrong? ► PCBWay $5 for 10 pieces www.pcbway.com
Much more info in my GitHub:
github.com/RalphBacon/247-Err...
It's the perennial problem of being able to log an error, in Real Time, so that we can accurately determine where the problem lies with a project that suddenly stops working.
Is it the Wi-Fi? Out of memory? Can't read the SPIFFs partition? Or something else.
I'm designing a very small, dual 7-segment display, just like you find on certain motherboards, to indicate where the problem might be.
Using one industry-standard, 8-bit Shift Register per 7-segment display, we can easily pass a value to a common function to display an error code. I might even have to write a simple library! 😁
► The circuit is based on a Texas Instruments' suggested circuit. See my GitHub for full information:
github.com/RalphBacon/247-Err...
We can use SMD versions of the 74XX595 and place them on the opposite side of the PCB of the 7-segment LED. If we use a very small (0.3" or smaller) I reckon we can design something that could be easily used in any project at minimal cost.
► List of all my videos
(Special thanks to Michael Kurt Vogel for compiling this)
bit.ly/UA-camVideoList-RalphB...
► If you like this video please give it a thumbs up, share it and if you're not already subscribed please consider doing so and joining me on my Arduinite (and other μControllers) journey
My channel, GitHub and blog are here:
------------------------------------------------------------------
• / ralphbacon
• ralphbacon.blog
• github.com/RalphBacon
• buymeacoffee.com/ralphbacon
------------------------------------------------------------------
My ABOUT page with email address:
/ ralphbacon - Наука та технологія
Capture exceptions in the EEPROM. First location stores the offset of the next free memory location. If you expect many exceptions configure a circular buffer. Love these videos.
EEPROM sounds a good bet. Circular buffer too. I'm working on what works best now! 👍
One idea that occurred to me would be to do what they do for car ECU's. Store the error codes in the internal flash when they occur, in order in a dedicated area, and if there are any error codes turn on a light. As an error occurs, you check in the list of stored codes to see if its already there, and if not you add it to the list. You could then add in functionality to read and clear the codes at a later date. If the gadget fails completely, you might still be able to read the codes using a device programmer, as I know the Atmel device programmers can read the flash memory, I presume ESP32 etc would be the same,
Sounds do-able, Ian. I'm still working out my options. None of them are easy. Or work in all cases.
Hey Ralph, a few thoughts for your project:
if you want to capture the error output, a webserver is not the best option: any loss of wifi, and there are no more errors. What you can do: SPIFFS (i.e. LittleFS) to the rescue! Just write a logfile to the otherwise unused FLASH. I did a little video (german - but I guess you'll get around) on how to use LittleFS as a temperature logger with a small web interface on the system; I guess that could be adapted to your project. And since the ESPxx acts as a server, you can get the status of the system, even if it's placed somewhere normally unreachable.
If you want to do some "still alive" logic, you'd probably need a second server (that can be an ESPxx, too). Your system sends periodically a "heartbeat" to the control server (all over Wifi/ESP NOW) - if there's no heartbeat, the control server makes noize, blinks LEDs... whatever you desire :)
On the thought of really small LED Displays: try googeling HPDL1414 - really tiny, should be compatible with yout idea with the shift registers. I used two of them some time ago in a four-letter-word-generator... they work like a charm :)
Keep up the good work - I'm always enjoying your videos!
A small web interface is fine (my workshop heater controller has one, shows all the temps from all my sensors in and around my workshop) but it only works with web-capable devices. So ESP32s are no problem. But an Arduino? That's where a simple display might be useful.
Those HPDL-1414s are really butt ugly. I've found some 0.2" (5.1mm digit) that are really pretty. I'm hoping to show them if the project works!
Incidentally, your workshop is about as warm as mine in the summer. I'm seriously thinking of a split level aircon system so I can actually sit in here without profusely sweating! 🥵
Good to see you back. I trust you had some nice warm days.
I see that you finally went for some propper connectors.😁😁
Yes I did, and very good those KF2510 connectors are. But the correct crimping tool is a must, too.
This is an excellent video that highlights a very common problem. Thx. I really like the little .9” OLED displays for this. They are about $3 each and smaller than the segmented digits. They are I2C so take few pins. You can display quite a bit of debug and error data on them. I like the comment others have made about storing past errors in EEPROM as well.
Very welcome! Yes, stage one in displaying an error will be done first.
For one project we needed to be able to get error code's and serial number from a set of devices where the only interface to the user was the power led. This was a problem before IOT was not even an egg. The answer in the end was to send the data via the power led, we just put a photodetector over the power led and received all the information required. the led was pulsed fast enough for the user not to notice by eye, also this was long before mobile phones had cameras so detection buy the customer was not a problem.
we had t think outside the box, or outside our box ;-)
That's a pretty interesting solution. How did you receive the data, if I may ask?
@@1_HighDuke we had a handheld rs232 terminal, which displayed the data. The sensor just turned the light pulses in to 5V logic signals for the terminal to read.
So you invented Light-based Wi-Fi even before Wi-Fi was invented?
HI,
with one 7segment display you have allready 8 leds giving 256 possible "codes" to display if you are willing to diverge from numeric systems. What is much less complex than reporting the last error might be to display the last successful operation; or entering and leaving relevant subroutines. Knowing the operation of your software should in most cases indicate where it got stuck.
Yes, good idea to display the Last Known Good State. 👍
Amateur ish, but so arduino ish at the same time:
Extra I2C connector on the board costs next to nothing, both in terms of price and board space.
In code log events using SW Serial and error codes to EEPROM.
In case of fault connect BT SPP module like HC-05 to that I2C connector, connect from Android with treminal app of choice and reset to read out error codes (setup routine) and debug running code.
Or even add a button to reinitialize BT module on press to avoid resetting (and e.g. triggering self-test routine).
Yes, the error code has to survive a reboot so writing the error somewhere is a must.
I read quite some comments..and a way in the middle may be the following : use circle-buffer in EPROM... but use a beep/blink led to show THAT there is something to look up.
than you know, it's worth to put serial on.
even your LED showing green(=all ok) may be interrupted for some (visible) millis
..to indicate a (change)in ERR-Buffer.
Yes, that sounds quite a neat solution. Easily accessible using a web page too. I will cogitate more on this, thanks!
Amazing channel!
Glad you enjoy it!
Great content as usual!!! Thanks a lot!!!
Glad you liked it!
microSD card writer/readers are small, cheap and easy to use; anything that can be written to the serial monitor can be written to microSD. A clock module can add a timestamp. If written at regular intervals, there's an audit trail of when the Arduino crashed.
I need to intercept that output to the serial monitor and route it to the microSD card.
@@RalphBacon Are you asking me how to do it? If so, I'd be happy to oblige: I could publish a sketch to github if you like. Tim
Hi. I would use a part of the embedded EPROM as a event log. If RTC is available, it could be recorded too. So you can log last xx error codes (10 for example).
Indeed, using a small circular buffer in the EEPROM is a good idea. Using half - 512 bytes - seems about right. Simplicity leads to fixed size records: start with N bytes for the sequence numbers - the index table. Divide the remaining space by N for the individual records. Each record starts with an error code (8, 16, or 32 bits - your choice), that is followed by a zero terminated string, then the last byte of the record is the same sequence number as the one that went in the index table. A sequence number of zero means 'not used, ready to be used'. Sequence numbers go from 1 to 255 and back to 1. A quick scan of the index table will find the most recent message. e.g. If there are 250, 253, 254, 255, 1, 2, 0, 3, 251, 252 then 3 is it. The point of writing the sequence number at the end of the record is the verify that the message has been completely written. If the sequence number from the index table and the record don't match then that writing is incomplete and the entry is invalid. RTC stamps can be added easily too, maybe using the Unix 32-bit timestamp, or some more verbose representation.
A circular buffer in the EEPROM could work. On reboot, the Arduino (or whatever) would read and show any "last error". Hmm. Brain cells are ticking.
There are some I2C EEPROM modules that you can use for MC’s without built in EEPROM. Good thing is you can move them to an other MC for debugging
Hello Ralph,
I would use a ring memory in the EEPROM in this case.
In the first cell the pointer is stored (e.g. No. 2)
then in the following cells the respective error code. When the ring memory is full, the first value is overwritten again. If enough EEPROM is available, the corresponding time stamp can also be stored in this way.
With an ESP8266/ESP32 I would create a text file in the SPIFFS as "Logfile.txt". In addition to the error code, a time stamp can also be stored here.
I hope this helps you.
Greetings
Frank
Thanks, Frank. Yes, some sort of circular buffer might be the answer.
By the way, a 0.42" OLED is even smaller and perhaps even more useful.
The ones I've ordered are (allegedly) tiny 0.28". I hope I can actually read them.
Well, I've had to do this professionally for many years and all these schemes are dependent upon a coherent processor writing coherent data to an (for lack of a better word) 'error-log' device; furthermore there appears to be no method past the error-number to display relevant failure data..
The problem is, if the main 'CPU' has trouble or becomes corrupted, either temporarily through say a transient or worse a hard permanent failure, you don't have the 'intelligence' available to handle this corrupted condition. It is fine for peripheral errors but I've found that when something is upset, usually the main system has played a part (mostly by line transients--or latent stack-overflows etc.), to the point that it can write false reports especially if you limit it to a single/double LED display (i.e. the display might show something but it is not truly valid because of the limited display combinations).
So, the only solution that I have found that is the best, is that of a continuous operation-log--(with sometimes an brief exceptions-data log) that we are constantly writing operation/results to this log whether the operation is correct or aberrant.
In order to facilitate this, we have to have a mechanism with sufficient storage-depth that you can go back and fully understand the execution-stream that was taking place. When you have a pure software (resident on a PC or mainframe) system, you use a text-based sequential file that logs everything (sometimes down to the user keystroke/mouse-click) to the level of granularity that is useful. I have had clients that corrupted their databases and tried to blame it on my software but when I showed them the keystroke/resultant data-stream, it quickly ends the argument!
On a microcontroller system, the method I use is an EEPROM of sufficient size to accommodate enough event-capture to be useful. This does not have to be all that large because an error and its relevant failure-data are usually fairly short. Given this, you want to still use a 'circular-file' type of system whereby old good data gets overwritten by current whatever data. So, unless the system really goes wacko and just writes tons of gibberish to the error-log, you are pretty much assured to have something to work with.. In the case of the external EEPROM, you can even unplug it and interrogate it on another system. In the 'old-days', I used a static-ram with a lithium battery backup that I could detach in a similar manner.
Lastly, I utilize Morse-code to use as an annunciator for really small systems whereby I can review anomalous data by requesting it 'playback' any exceptional data collected (which of course can be segregated from the afore mentioned total data-stream) and using Morse code can be quite verbose using only one I/O pin! Alternate to this is of course your system whereby you're using 'trouble-codes' just like on a vehicle. Anyway, super video and it is indeed important to know what went 'bump' in the night! 73...
Well, if the main processor goes fubar then there is little we can do. But, as you say, reading the log back to the point of failure can throw some light on what _might_ have gone wrong.
Hopefully those mega errors are few and far between; in the Arduino-style world it's much more likely that we couldn't read a sensor, or the Wi-Fi would not connect!
I'm hoping my dual 7-seg displays are easier to read than Morse code (which I knew once, as part of my [teenage] radio amateur's exam but never progressed it, so now I know nothing of that any more).
I have always wondered and a continuous log sounds great. Since these makers seem to use serial debugging and logging, maybe a good device is an ESP32 serial logger with SD card and web interface as just the logging device? It can be kept as a toolbox device for many projects.....
Motherboards still have beep codes to this day. Beeper is just not mandatory now, but there are always pins for external one.
POST codes 7seg displays is more of a premium feature now.
They haven't invented anything new apart from logging 10-15 entries of codes + timestamps into EEPROM, but that's a server segment feature.
Ah, also "Wait for F1 if error", that will prevent boot until user input in case there was some severe fault like failed overclock or memory speed profile.
What about the PC error "Keyboard not detected - press F1 to continue"?
Great video as always. As to the old BIOS beep codes as I recall 3 short beeps and 1 long was used to signal a video problem, as …_ is V in Morse code.
Any beep from a computer usually signifies a problem IMHO, Bruce. It's what they live for.
@@RalphBacon oh so true!
With Neopixels you can reliable show at least 7 states/messages and have fairly easy indication on a single one and it will remember the last one.
I like the idea, and they're fairly inexpensive nowadays. The only thing I'd be concerned about is how much memory the libraries needed to run NeoPixels would take.
That depends. You do not need the large NeoPixels libraries, I did my own routine for handling a single NeoPixels on the old Arduinos and it do not use much memory.
You mean seven colours? Well, yes, and just using one wire too. How about a combo of colours and flashing ("BIOS beep code") errors. Green (short) Red (long) Blue (long). Wow! My mind boggles.
Yes, I mean 7 colors, you can add more if you play with the intensity, but it gets harder to decode. Any flashing requires the processor to be involved, a steady color do not.
The code I use to handle the NeoPixels is about 30 lines for a Nano/Uno.
You could use a single EEPROM register to hold a byte from 0-255 and only update it when an error occurs.
Alternatively you could use several and iterate through them to show the last 10 errors since you last read out your errors
Yes, that's an idea.
Well, one of my projects has an actual beep code implementation!
I included a function that can send Morse code via a beeper, and optionally - a compile time choice - an LED on a separate pin. When I hit an error situation in my main code, it calls a "signal error" function that uses the Morse function to send S-O-S, followed by the integer error code passed in. Repeat.
I figure the beeping would catch my attention if I was walking by, or happened to be in the same room. An LED (or 2 digit display) will only be noticed if you're actually looking at it, but an audio signal interrupts you to make you look at things! A beeper takes only 1 pin, and the optional LED would take the count to 2.
Admittedly, I didn't implement anything to retain the error after a reboot, but my use case didn't need to... If it isn't working, then I treat it just like a modern Microsoft operating system, and reboot. At least I don't have to format and reinstall! :)
I wonder if you could wire the LED in series with the beeper so you get both visual and audio notification from one GPIO pin?
@@RalphBacon It's certainly possible to drive both from a single pin. I have actually breadboarded an active buzzer connected to the Arduino built-in LED pin, which of course has its own on-board current limiting resistor, so yes, it can be done!
But I don't think wiring them in series would be the best choice, and with different kinds of beepers it can get... let's call it _tricky_ ?
A passive peizo beeper is basically a capacitor, so a series LED is going to be driven with pulses (at audio frequencies - which may not be what you want) of very high current. Instead, you'd probably want the LED in parallel with its own current limiting resistor.
If, on the other hand, the beeper is an active unit in series with an LED, then you need to worry about the current draw through the beeper vs what an LED needs. Magnetic beepers typically draw >20mA, while a piezo unit is
I think I’d go with a circular log file on an SD card. Then some sort of visual indicator (led, e-paper, split flap display like in old train station displays) to tell if SD logging isn’t working and/or to say there is sufficient info on it that merits taking a look at the data. (And perhaps to show or indicate the most egregious error in log file)
I'm going to try some sort of logging system to SPIFFS or SD for sure!
Another great video. You have great communication skills and explain things very clearly. I'm working on something of a similar nature (although not exactly the same) at the moment. It's an Arduino Uno with a TFT shield, which acts as a serial monitor. So, I can just plug it into the UART Tx, Rx pins of my esp32 and get it to print serial commands to the monitor. The motivation is a portable go anywhere serial monitor I can use for OTA updates on esp32.
On another note, can I please request a video on making a custom shield with pcbway (for example). So, I can just plug my TFT, OLED, temp sensor, INA291, motion sensor, ultrasonic sensor, etc... straight into the shield, in the direction I want, without all the messy wiring. Let me know if you've already done one.
I had something like you described, for use with PICs. Still got it, in fact. Worked well and ensured I only needed ONE display that I could use for all my projects when debugging "in the field". The drawback is that if an error occurs it's too late to see that error (it might not happen again for a while).
Regarding the PCB, you mean you want a generic PCB for a single Arduino and multiple sensors and displays?
@@RalphBacon Thanks for your reply. The original motivation for a project specific shield came from a diy "smart" (don't praise the machine) camera for object recognition, that I was working on with a 2.8 inch TFT and an esp32-cam. The TFT has a lot of wiring. So, I had to solder female header pins for each one to their own perf board and connect the perf boards back to back, so the TFT and push button was on one side and the esp32 cam was on the other. My soldering skills are not very good, and it was quite a job... got it right on the second one. I thought about designing a pcb shield where I could plug the esp32 in one side and the screen the other side. I looked up some tutorials, but they all seemed a bit of overkill for what I wanted to do. BTW... this is the project I used your "ps_calloc" hack for.
Error monitoring? Well many professional coders, generally, turn the back to that one (rather like a guilty dog sitting in the middle of the remnants of a roast chicken in your kitchen). I did come up with a solution to the power down - up problem. One of the first projects I come up with when I returned to electronics was a solution to the "switch it of, wait 30 seconds, then switch it back on" situation with a mains device. Using a defunct wall wort charger, I put 555 timer, push button and a mains relay (of course resistors and capacitor too) into the case. So when I needed to switch off ... etc. I only needed to press the button and walk away, 30 seconds later the power was restored. No MCU was harmed or even used in this project. Later on the thought crossed my mind (a rare event in my case) that a similar approach approach might be useful with an Arduino, that is a circuit totally independent of the MCU that would respond to a trigger pulse from one pin of the MCU by interrupting the power supply to the main circuit. Because I wasn't using mains supply, it didn't need a relay etc just the 555 with its timing resistor and capacitor and a switching FET; all upstream of the supply to the MCU. The pulse would be generated by an error routine or the watch dog interrupt (it only had to put a 1 on the pin, the FET would take care of the rest). The experiment was successful but never got beyond the breadboard stage. I cannot solder anymore, I only enjoy the hobby vicariously by channels such as yours. Just saying. Oh! great video, Ralph.
You're almost describing the solution in videos #190 & #194 which I still have and work well (an external watchdog that kills the power to the entire circuit if it doesn't get reset within a few seconds). Yes a good old 555 timer works just fine. It doesn't keep the error in EEPROM though, that I still need to do.
Hi Ralph, great challenge/project. In terms of capturing some system state data (perhaps as the power is about to fail) I tend to think about eeproms - e.g. Microchip AT21CS01/AT21CS11 single wire devices ... good for 1million+ writes and should hold data for 100 years so hopefully we might notice something by then. On reset have the sketch check the eeprom state and if it finds a message there then use an LED to blink it out .. perhaps use Morse code for fun, then another mini-project to make a separate Morse detector/decoder to display the messages. If you have the luxury of an extra button to wipe the eeprom then great, if not wipe it after some time period or number of times transmitted. Just a thought.
Why stop at Morse Code? How about binary code? Semaphore? Why make it easy to find out what the error was? 😂😉😋
@@RalphBacon ... 😀 got to find a reason to practice those skills or we loose them.
Yes, any interface but I could see the advantages of a non-contact, minimal tech solution. All the best.
Don't now if this makes sense. But you could use an output pin, sending a specific voltage. You can then connect one of those cheap voltage monitors, it is ready and build off. If you use voltages above 0.5 Volt you can keep the voltage monitor switched off with a transistor or FET, and only let it light up in case of an error. Or, just flash an LED so you know you need to 'read' the output voltage. No need to say you must divide the Voltages in ranges, so small differences can be rounded up or down. Also note: you do not need to keep the voltage monitor attached, you can just attach it when there is an error situation (shown by an LED). I have seen may comments about SD card and EEPROM.
In most cased you wil have 'missed' the error any way, the code does not have to stop 'at' the error (overshoot).
Want to know a fun fact? So every now and then I am standing still, waiting for my fire alarm to blink. Haha, just to see if the battery still works. I don't want to really test the alarm (1) it is loud, (2) it drains the battery at that moment. I already noticed the firmware tests the current draw so every now and then. In any case: the simple blip of the LED tells me it is working. And it will beep if it low battery (making et even lower that it is, but it works very well).
The voltage on GPIO pins is generally zero (or as near as) or +5v (or as near as). Nothing in-between unless you're using some sort of digital to analog conversion. However, I could read a series of pulses (like the computer BIOS beep codes I mentioned) I suppose. Then again, if the unit is permanently powered I could just flash an LED and watch that.
Sound a good idea
I think so too!
I would use a secondary controller, which can regularly wake up to save on battery and periodically poll the situation of the device you are concerned about. I'm a massive fan of having an independent monitoring solution. With that, I can decide what states to collect, how to store it, and if I want to forward it. The SN74HCS594QDRQ1 looks like a good match for the application 7-segment readout, for example, monitoring two significant issues, i.e., a random number of reboots and dead. The display can visually show the number of times rebooted and flash furiously to indicate loss contact, acting as the heart-beat indicator. Just my2c. Cheers.
Independent monitoring is fine for larger projects that are permanently powered. It's the little projects, possibly on battery that are tricky to monitor.
It might be that there is no other way to monitor those other than to either send out an error message (if it has some sort of Wi-Fi) or write to a small, cheap e-Paper display.
@@RalphBaconI agree with you on the target small hobbyist project. Still, it will be a challenging project to try to realize my alternative and use a very cheap controller and don't implement any wireless forwarding. Can it be done? I have to think a bit about this and weigh the pros and cons with your upcoming solution; anyway I eagerly follow how your project progress. Cheers.
Exiting project Ralph, Pinball machines have been flashing errors for decades but nowadays the easiest way must involve some sort of non volatile memory and as for the choice for displaying the data we are quite spoiled these days, so Nixie Tubes perhaps ?.......cheers.
Nixie tubes! I love them. OK, that's the answer then. Cheers, Andy!
One of the first commercial projects I worked on (back in the 1980s) flashed Morse code on an LED to indicate an internal error. It's a good thing that it almost never failed in the field since getting a customer to accurately report a series of long/short flashes is nearly impossible.
For a project with a Bluetooth capable chip, I wonder if it would make sense to publish error values in an attribute. Then use one of those Bluetooth scanner apps on your mobile phone to read the error codes or messages. Of course, that's only useful if Bluetooth is functional. And I'm not sure how well you can mix Bluetooth and WiFi on an ESP32.
You can run both BT and Wi-Fi concurrently on an ESP32 - but what about the humble Arduino (and similar processors)? Morse code... well, BIOS beep codes are similar, right?
With the ESP8266 write the error code and UTC timestamp to 'system_rtc_mem' read error(s) via telnet ('z' reset last error), or send via MQTT to a system/error topic with retain set. I always have a heartbeat LED 13mS on, 7Sec off = OK, faster for an error.
Sending the error to a centralised point would be fine but the Arduino can't do that without extra hardware. But good for other μControllers.
even simpler: use diodes to display a binary number. you can add as many as you need for the number of error codes you have.
Yes, that was on my list too. 3 LEDs gives 7 possibilities, more if the LEDs are bicolour. My new motherboard uses LEDs rather then 7-segment displays.
Of course the seven segment LED can be read as a 7 bit number if you wish rather than a digit. It's all in how you interpret the data.
Hi Ralph, I watch every video and have followed you for years, Great Tutorials. In this video you mention a temp sensor in your attic using ESP NOW. I have moved into a new home and am having problems with temp differentials in various parts of the house. It would be great to be able to monitor the temps at several locations and perhaps log them to the cloud for future study. That way I can see what the old readis were and then could compare them to the NEW readings after I make a change (Hopefully made it better, but not always). Could you share your code on your temp monitoring system? I think others in your subscribers group might also be interested!
Take note that ESP-NOW sends data from one ESP32 to another. No cloud involved.
However, my Home Alone system (to monitor my mum's activity level) does log data into the cloud (ThingSpeak as it happens but could be any one of a number of Cloud data providers). Telegram is another option. Many of these Cloud data providers allow free access for small amounts of data (4 updates an hour, for example. I think Telegram allows 12 an hour.). If you were thinking of logging more you may have to pay to do it.
It sounds to me that you need the second method of recording data so that you don't have to do much except look at it to see how your efforts are affecting that data over time. Someone has written a ThingSpeak widget for Android phones that display the accumulated data over a day/week/month or custom period. I use that to monitor my mum's activity levels.
I'll think about whether it is going to be of broad interest to share this Cloud data upload with others, given that IoT is all the rage these days!
@@RalphBacon You mentioned that you had several ESP's sending ESP_NOW data to a unit for your home use. That is what I referring to. Was interested in seeing your code for this temp and humidity sharing. I thought there were problems with using ESP-NOW to collect the data then with the same ESP board connect to wifi to send data to the cloud. Could be i'm just confused!
If a sensor or attached device hangs, write a code to the EEPROM, reboot, read the code in setup, display on LED.
That's plan #1 so good we're thinking on the same lines!
How about sourcing avery small epaper display. Have your functions send the codes as your executing. If the project hangs, the e-paper will still have the last error code.
I used to do this with PIC projects but the difference is that the I don't want the display to be a permanent part of each project (too pricey). If I can connect afterwards, fine, but by then chances are the error has already occurred.
How's about storing the last n errorx in a circular buffer in the Arduinos EEPROM and have button to sequntially show them on your 7 segment display? :-)
That sounds quite feasible. I shall ponder some more on what you suggest.
A helpful idea, unfortunately with IOT devices that are designed to run on minimal current drain doesn't this impose a further unwelcomed continuous load on the battery.
That's the issue with battery powered projects. My rubbish bin reminder only runs for about 10 seconds per day. I can't keep it switched on longer or the batteries will die very quickly. I need to use that e-Ink paper display, I think, in that case.
I think two lit 7-segment displays will use too much current for battery-powered projects. First, I would think that one display would be enough. If you include the letters and other special characters that can be displayed, you probably have far more different error codes than you would ever need. Second, I suggest running the CC pin through a switch or jumper to ground so the display lights up only when you need to read it. Finally, rather than populating the eight segment resistors, I think you can get away with using just one CC resistor. There would be some variation in brightness depending on how may segments are lit up, but if you eliminate the 1, and put tails on 6, 7 and 9, I suspect it would work well enough for this purpose.
Yes, for battery powered projects it should only display the error code on demand, just as you suggest. Good idea. I was going to use a resistor network, if they exist at the right resistance, or perhaps just SMD components are small enough. But, as you say, we're not after perfection here so maybe a single common resistor will be good enough. All good ideas 👍
Error reporting routines are ok until the processor gets stuck in a loop, HW watchdog is a nice addon, oh I dunno, maybe a digital out that pulses, charges a capacitor, if the pulses stop the cap discharges, that removes power from the arduino, then another bit of electronic trikery to repower it, gets complcated i know but a hw reboot is always a sure fire way, maybe a 555 timer for nostalgia
My external watchdog uses a 555 timer to totally switch off the Arduino and everything else! You must have missed video #190 and #194 ua-cam.com/video/WpihLPvY9Ac/v-deo.html
I had an issue with chicken coop door controller where I could see when it was failing. I put an OpenLog logger module into the unit and logged the serial line where I outputted constant status data so I could see what was going on within the software.
Which is effectively what I had to do with my Rubbish Bin Reminder project: I connected my tiny laptop to the serial port (USB) and just left it running for several days until it went wrong! Not great for wires an I had to plug the laptop in too!
I have used E2PROM in the past to store codes, one had an external one so if the MCU failed to boot for any reason I could still read the last code present with an external reader. I have also used SD card as the project already had one but that was more for system errors like network connection errors rather than MCU issues.
Yes, SD card is easiest to transport (if you can get at it) and just plug it into a PC. But EEPROM / SPIFFs is also good if you can read it (via the microcontroller). I'm looking at options right now.
@@RalphBacon Yes, I guess it depends on how often you need to write to a certain part of the flash vs how many write cycles it can take, also you have to erase a "block", but for most applications even though some people complain about "wearing out the flash" it isn't an issue. Some of my work products have a E2PROM in a socket so it can be replaced or if a unit fails you can move the config to a new unit, works very well just depends on your end application / requirements.
an extra device that reads and translates the flashes to text messages might relief the need of a text inventory and can decode messages more easy .you can even use faster blinking timers .
Very true. A tricorder to read the flashing error LED. Sounds cool.
@@RalphBacon :) tricorder , lol , i looked it up .
my inspiration was more modest ,more like how television devices receive signal from remote controls . but also and visual for a human .
If you just use a big enough capacitor that can deliver the energy to your monitoring circuit, so the circuit you make must be able to continuously monitor for example the serial port looking for some specially preprogrammed errors which it can trigger of, then after the trigger the capacitor gives you a few seconds to capture the error code and save it in a flash memory chip or you can use an EEPROM chip to store the last received data, then when you first put power to the error monitoring circuit it will display the error code.
You can even make it battery powered instead of using the capacitor to continuously show the error code on the display until you reset the microcontroller, the point of making this useful is that you only have to be able to capture some fixed set of data when the error occurs, then save that to any kind of memory and display it instantly and always or only temporary, whatever you like the most of the two latter options and that's about it.
Can't be too complicated to make something like this I think.
Well, Ricardo, I think it is more complicated than you might imagine. Battery powered devices must be treated differently.
And devices without Wi-Fi capability the same. I've tried capacitors (super-caps) and they didn't work at all. Some of those chips are very power hungry!
@@RalphBacon Hmmm, I thought it could be made simple like I suggested but apparently I was wrong, now I'm curious what you come up with or someone else comes up with.
I noticed that you are able to control the red/green LED colors using only two wires. Could you let me know what LED this is and how do you switch between red and green using only two wires? Thanks
those 2 pin dual colour LEDs have two internal LEDs which are connected in parallel but in opposite polarity. So when current passes through one way it will be one colour and when current runs through the other way they are the other colour.
one way to drive this would be to use two separate outputs that can be pulled high or low individually connected to the LED in series with a suitable current limiting resistor. the outputs would need to be able to drive the LEDs current, say 5-20mA depending on the LEDs.
It's a bi-color LED. It's essentially a red and green LED in a single package, with the LEDs wired with opposite polarity. With one pin high and the other low, you get green; reverse that, and you get red. If you alternate the polarity fast enough, you'll get both red and green, which makes yellow.
If you alternate the polarity fast enough you get a dirty orange/brown rather than yellow. Yuk!
Tiny display? Look up HP QDSP-6064 bubble display.
You can latch the display and shift to the next digit before saving a new error code. Use a controlled shutdown to record a zero error.
I will look, Bernd. Bubble display? Is the bubble a magnifying glass? In the 1970s there were calculators like that.
What about using a small microcontroller for that, using a single serial wire to the mothership, you could add a watchdog/reset function on it, and it could drive the segments, and store error codes. (attiny167)
etc.My thoughts also, use the pin that would go to the watchdog and send data down it to indicate status good or otherwise, the watch dog would record the abnormal status or no watchdog reset pulse then reset the master.
Yes, good suggestions except I want to be able to permanently add this to a project as well as on an ad-hoc basis. I guess there is no one-size-fits-all here.
All of my home auto gubbins talks via mqtt to node red on a pi. Any errors or warnings are then sent via Telegram to my phone. I've setup different bots for various streams.
Most things also send out a heartbeat too, that fires a warning if it stops for too long.
There is a secondary pi and they monitor each other's heartbeats.
I'm beginning to think that MQTT / Node RED/ RasPi would solve all problems if the device can communicate wirelessly.
soundquality?
Always 100% except this time I had the sound turned up too high. So 99% then. 😳
@@RalphBacon 👍😉
Thumbs up for the two brain cells 😂
Hush! One's asleep right now and I don't want to wake it. 💤
If you can address the 7 segments in the display individually then a single "digit" can report 2^7-1 = 127 different error codes (obviously not all legitimate 0-9 digits but so what).
Since you need non-volatile storage (so that data survives a power-off-on cycle), how about storing the errors (and status maybe) in a log file on a micro SD card?
Or storing them in EEPROM / LittleFS / SPIFFS. Yes, needs to happen.
How many hobbyists go to the trouble of catching faults in their programs.
I was looking at a bit of code where the main function of the code was less then 1/2 an A4 page, the error checking which checked the data coming and the data going out, to see if all was withing expected limits was 4 1/2 A4 pages. I expect the pre and post error checking took far longer to write than the code itself.
I think most of us write in a "Happy day coding style" which means on a happy day all goes well, on a bad day the result is switch off and on again.
it's a real test to your programming skills to write code that will detect the fault, log it and get itself back running with out user interaction. as if it's in your loft and you have to go up there every time it falls over. it will soon be switched off for the last time and left to collect dust up there.
I think most of us are in this boat :) Although, as someone who is planning on making a consumer product (however low-volume it may be), I too have started thinking of ways to deal with errors & crashes -- mainly so that the consumer can appropriately communicate what's wrong or even troubleshoot the problem themselves based on instructions in a manual.
@@1_HighDuke simple displays.
Could be
1. green power light is good.
2. Slow red flashing power light with pause, count flashing for error code.
3. Fast continously flashing red, major fault turn off.
If there are outside requirements e.g. sensors then there could be a status indicator for each one.
The thing to remember is each adds cost and puts price up or profit down.
Firstly, I can add the external watchdog that re-powers the entire system. Videos #190 / 194 describe this and it works well.
Secondly, I could log the error by the umpteen ways suggested in these comments but as you say, going up into the attic to see them is not a great idea. No one size fits all here.
Hi, as a long time subscriber I thought id give some general constructive criticism :)
You could really benefit from having a graphic designer work on your thumbnails. They're very dense with details, images and contrary colors.
It can be pretty overwhelming.
Just think of it as hiring someone to maximize the S/N ;)
I think this is very personal; you may find it not so perfect, but others may be ok with it. I think content is king for more subscribers, and Ralph spends a lot of time making thumbnails, making each episode's content look fun and attractive. So my take is not to waste time with more "cosmetics features." Cheers.
@@Cptnbond I absolutely agree that content is king :)
But that does not detract from the power of presentation!
This is mostly relevant for piquing new subscriber's intrest.
But also, as someone with adult ADD, I can attest it absolutely does affect perception of the video and whether I want to watch it.
They're not mutually exclusive concerns, ya'know?
The last comment: I do not use thumbnails to decide if I should watch any of Ralph's episodes. Whenever a new episode is released, I immediately watch. They are always worthwhile spent time. The thumbnail view is used whenever I have an Arduino-related or general controller issue; my first stop is to first search on Ralphs's videos with the search function and second scan the thumbnails. Here is the point, the latter is beneficial and designed to reflect the content. I think they do this very well. Cheers.
Hmm. Interesting point you make Jonathan.
I decided a long time ago (6 years?) to make my thumbnails recognisable; and I believe they are, with the green cutting mat background and bold yellow/red video title.
Whether that makes them (un) attractive or not is a bit subjective, but I'm hoping they are easily readable and might encourage viewers to click on one. Some UA-camrs have just the presenter and a big bold title that is not particularly consistent across videos - but as they have hundreds of thousands of subscribers I guess that is not their focus!
I'll take your suggestion on board and see whether I can do anything to make them less "dense" (I guess you mean "busy", as in too much writing).
@@RalphBacon Hi Ralph, thanks for taking the time to read my comment :)
Yes, by dense I meant in terms of information, as in busy.
My meanjng was not only the choice of colors on the text, but also the amount of text, icons and objects.
I think of it as a signal-to noise thing (emphasizing everything is effectively emphasizing nothing) as well as the definitely subjective esthetic opinion
But perhaps for browsing back-catalog (which I havent done much admittedly) it works. Just throwing in my 2 cents :)
Where is my comment again? What is going on here?
If you put an external link in your comment it will get zapped by YT. Nothing to do with me, honest!