Notifications
Clear all

10/18/2023 Map Stopped Working?
Visit this post for the fix

Remote I/O Error writing to OLEDs

12 Posts
4 Users
0 Reactions
1,762 Views
 Stu
(@stu)
New Member
Joined: 5 years ago
Posts: 2
Topic starter  

I'm seeing the following error message after the map has been running for a few minutes.

Traceback (most recent call last):
File "/NeoSectional/metar-display-v31.py", line 646, in <module>
oledcenter(val, ch, font, arrowdir, dimming, toggle) #send airport and winds to proper oled display
File "/NeoSectional/metar-display-v31.py", line 165, in oledcenter
  tca_select(ch)                         #Select the display to write to
File "/NeoSectional/metar-display-v31.py", line 162, in tca_select
tca_writeRaw8(1 << channel) # from Adafruit_GPIO I2C
File "usr/local/lib/python2.7/dist-packages/Adafruit_GPIO/I2C.py", line 107, in writeRaw8
self._bus.write_byte(self,_address, value)
File "usr/local/lib/python2.7/dist-packages/Adafruit_PureIO/smbus.py", line 250, in write_byte
self._device.write(data)
IOError: [Errno 121] Remote I/O error

Afterwards, the OLEDs are static and the script no longer attempts any OLED writes (LEDs continue to function). Stopping and restarting the map script resumes normal operation until the next error.

I've got an 8 OLED setup which worked fine on the breadboard. This symptom developed after soldering the OLEDs to a perf board, so it's got to be related to the wiring. All the connections check out on a meter, and each OLED functions without error when its part of the wire package are connected as a single display.

I used UTP cable to connect the SCL/SDA lines to the breadboard where the multiplexer still lives. Could I be seeing a noise issue because of the twisted wire? In my intermediate testing stage, those UTP runs are about 16" (will be cut down to about 6" when finalized). Could length be an issue as well?

Thanks for all the work!

Stu


   
Quote
Mark Harris
(@markyharris)
Member Admin Registered
Joined: 5 years ago
Posts: 559
 

Hi Stu, I'm impressed by your progress! You are correct in saying that there is an issue in the wiring. I've had the same issue from time to time while building OLED displays and it seems to be more prominent with the max number of OLED's. I have no insights to the issue of noise, or wire length I'm sorry to say. I had to go back and resolder some of my work that I thought was sloppy. I also noticed that if I were working around the project while it was running and I bumped the lead wires that the same thing would occur. So I believe that wiring needs to be bullet proof. I'm sorry that I can't give you more insights to this. But maybe together we can come up with some ways to remediate the issue. I'm currently in the middle of a build of the US using an 8 OLED module I built. So as I'm working on it I'll continue to investigate. I attached a pic and vid of my OLED module to help compare. - Mark

8oled

 


   
ReplyQuote
 Stu
(@stu)
New Member
Joined: 5 years ago
Posts: 2
Topic starter  

I've updated my setup and used JST XH connectors for each display back to the MUX. It's much more stable, but will still occasionally get an IO error writing to the OLEDs. 

Being lazy and not wanting to solder the connections for a 4th or 5th time, I decided to use a code approach to restart the display script if it stops running. Not the most elegant solution, but it will keep it running one way or another. (This is the first time I've ever touched Python code, so be gentle if you see some poor technique!)

The solution is a new watchdog script (check-display.py) and some additions to the startup.py script so that it includes the watchdog in the startup sequence. 

Feel free to enhance, replace or ignore as you see fit.

check-display.py and startup.py (zipped)

      

Stu

 

Photo2
image

 


   
ReplyQuote
Mark Harris
(@markyharris)
Member Admin Registered
Joined: 5 years ago
Posts: 559
 

Stu,

That looks awesome. Great job! I'll look at the script. I hadn't thought of using such script to check on it. Thanks for doing that. I'll see if it can be incorporated into the project. I'll be sure to credit you in the source code! - Mark


   
ReplyQuote
(@mezmer3365)
Active Member
Joined: 5 years ago
Posts: 16
 

So this is the error message I get when I hit shutoff map. Right now I have a single oled on a breadboard. Not seeing a wiring issue. 

Sorry for the less than ideal picture since I have it hooked up to my tv and can't screen shot it. Let me know what you think.

 

IMG 3603 2

   
ReplyQuote
Mark Harris
(@markyharris)
Member Admin Registered
Joined: 5 years ago
Posts: 559
 

The error you see 'tca_select(j)' is the script assuming you are using more than 1 OLED. With more than 1 OLED, the use of a Multiplexer is required, and the script has to tell the Multiplexer which OLED to send the data to. 

Since you are only using 1 OLED, the script does not need to address a Multiplexer. So the fact that this error is coming up leads me to believe that the 'Number of OLED Displays' setting is not set to 1. This is located under basic settings. Check this and set it to 1. Hope this helps. - Mark


   
ReplyQuote
(@mezmer3365)
Active Member
Joined: 5 years ago
Posts: 16
 

So I just checked and it is set to 1. I also checked the config file and it shows 1.

 

color_ifr = (255, 0, 0)
border = 1
leg_pin_nowx = 20
numofdisplays = 1
dimmed_value = 20
boldhiap = 1
oledused = 1
color_snow2 = (100, 100, 100)
legend_snow = 0
blankscr = 0
leg_pin_ifr = 18
welcome = "Welcome to Lance's Metar Map!"
max_wind_speed = 0
fontsize = 24
leg_pin_mvfr = 17


   
ReplyQuote
Mark Harris
(@markyharris)
Member Admin Registered
Joined: 5 years ago
Posts: 559
 

So maybe you found a bug that should be easily fixed. The shutoff.py script wasn't taking into account the possibility of not using a Multiplexer. Make this change in shutoff.py around line 83;

def tca_select(channel):
"""Select an individual channel."""
if channel > 7 or channel < 1:
return
tca.writeRaw8(1 << channel) #from Adafruit_GPIO I2C

 

Add this to the if statement - 'or channel < 1'.

Hopefully this takes care of it. You are now a beta tester, for better or for worse. 🙂 - Mark


   
ReplyQuote
(@mezmer3365)
Active Member
Joined: 5 years ago
Posts: 16
 

That did it! Ultimately I will have the multiplexer, but I wanted to test the one and make sure it all works. Again I impressed with your speed and knowledge. If you need anyone to beta test, I have no problem.


   
ReplyQuote
(@stevepeck1)
Active Member
Joined: 5 years ago
Posts: 0
 

Were there any more insights as to solving the freezing displays? I've gone as far as to use higher-quality solid wire for the clock and data wires. No consistent joy.


   
ReplyQuote
Mark Harris
(@markyharris)
Member Admin Registered
Joined: 5 years ago
Posts: 559
 

If you want, attach the logfile.log when the problem occurs and we'll take a look to see if we can figure out what's happening. - Mark


   
ReplyQuote
(@stevepeck1)
Active Member
Joined: 5 years ago
Posts: 0
 

I'm leaving a note here (and other help threads where I've been frustrated) in case it helps someone. I re-did all of the electronics and now appear to have solid reliability and consistent operation. I strongly believe that the basic jumper set had very poor crimped connections and this made for some intermittent and weak connections. I shortened all wire runs and used solid core wire for many components. For those situations where using the jumpers remained beneficial, I took off the black shielding with a needle and touched a tiny bit of solder to each wire connection and replaced the shielding. Any connection that didn't FEEL solid, got a light squeeze with a crimper before pressing onto the terminal. I also had an unnecessarily-long run for the LED data line, and this seemed to create a host of issues. Shortened and tightened and all appears well! Bottom line, TIGHT and short connections are very necessary for a bulletproof project.


   
ReplyQuote
Share: