OpenBikeSensorFirmware
OpenBikeSensorFirmware copied to clipboard
openbikesensor
switched the thingpuls SSD1306 lib to a custom fork
added a restart function to display.h that clears the grid, sends init commands to the display and restart its This will heal display glitches. This is performed every ~120 sec
Actually there is no need to fork the display driver. Adding:
class MySSD1306 : public SSD1306 {
public:
void restartDisplay() {
sendInitCommand();
resetDisplay();
}
};
to the displays.h and using MySSD1306 instead of SSD1306 should allow you to call the needed function.
Does it introduce a "flickering" during the re-init?
Ahh this is the point, were you can see I am coming from ANSI C. Stuff like that isnt online possible in C++ To fork the driver was the fastes way yesterday. I will fix this.
Yes this introduces a short flicker every 2 minutes. But at the same time it fixes glitches
https://user-images.githubusercontent.com/12426445/105814307-7e6f3700-5fb1-11eb-8c7a-55bce2608c63.mp4
Sorry, I did not feedback further... What is not clear with the video. Does it also flicker if the display was not glitched?
Yes it sadly does a short flicker every ~2 Minutes even if all is fine. The problem till here is, that we have no indicator softwarewise to see if the display is glitched.
Would be nice to have, but I think if you check the positions, it will be return expected values, even if glitched.
Might be we add an option. On the other hand, the current OBS of @Natenom does not have the issue any more?
Yes to have a config option might be good.
This problem wasnt Natenom exclusive anymore. I programmed this after Markus reported this with one of the 00.03 devices.
This problem wasnt Natenom exclusive anymore. I programmed this after Markus reported this with one of the 00.03 devices.
Sounds more like an electrical issue. Can we not get to the bottom of this instead of patching it up software-side? Does one of the owners of an affected device have an oszilloscope?
I dont think this would be easy to track down with an oszilloscope. You have to find the problematic Signal AND the luck that the 20pF of the probe doesnt fix the problem temporary!
Furthermore we have to take into account that, what ever this proble is, will also accoure to fewer experienced users. Yes, this shouldnt be a permanent thing, but if users have that glitch and no clue where it is coming from, this is a better solution than restarting the whole device
I dont think this would be easy to track down with an oszilloscope. You have to find the problematic Signal AND the luck that the 20pF of the probe doesnt fix the problem temporary!
Furthermore we have to take into account that, what ever this proble is, will also accoure to fewer experienced users. Yes, this shouldnt be a permanent thing, but if users have that glitch and no clue where it is coming from, this is a better solution than restarting the whole device
I just thought, if it affects multiple people, it might be a design flaw. If it's too high bus capacitance on I2C, the usual might help:
- lower speed
- smaller pullups
- add buffer(s)
To verify that it's the bus capacitance, a scope would be needed. The probe capacitance would only make it worse, no? ;)
I've done some research on this. Looks like it would probably be the issue to me:
The cable used in my OBS is a LifY11Y, whatever that means. Google spits out this info on that type of cable. It specifies 110nF/km capacitance. For the ~1m of cable I have that would be already 110pF. Add some stray capacitances on the board, the input and output capacitance of the devices. So we're at maybe 150pF or 200pF. We're running the I2C at 500kHz (which is a weird non-standard clock rate, but okay). According to this (TI SCPA054) that means a max capacitance of 400pF, or somewhere in that region (again, we're running a nonstandard clock).
Oh, and then we have 10kOhm pullups on SDA and SCL. That sounds way too much. I've found a reference from SCPA054 to this nice document: SLVA689, titled "I2C Bus Pullup Resistor Calculation". In there, the example (section 4) is exactly our case: 200pF, 3.3V VCC -> R should be between 1kOhm and 1.7kOhm. We're running even faster, so maybe 1.2k or 1.5k might be a good choice. Even with only 100pF at a bit faster rate, I get 2.2kOhm as the max.
All of this is assumptions. Sadly, I don't have an oscilloscope. But I think this is an obvious thing to test, since a) the numbers look like they are wrong, and b) it's not hard to spot too slow rise edges on SDA/SCL lines with a scope if you know a little bit how to use it. That's why I suggested it.
All what you wrote to the capacitence stuff is right, I checked and calculated this stuff some months ago too, and came to similar results. But with some different informations.
-
We already have a much smaller Pullup of 1k-1k2. The 10k is outdated! If you still found somewhere the 10k in a current branch, please tell me! If thought I have purged all of them. Also someone checked the rise edges with a scope, the are ok with 1k2!
-
We also reduced the bus speed to 200k for testing purposes. This chanced, sadly, nothing.
-
I added a dedicated I2C buffer for the display cable. This made things worse and I had a pretty high amount of communication problems with other I2C devices (temp Sensor) that were located before the buffer. An I2C Buffer also seems (for the moment) not to solve this issue.
What in mind was, is a bad ground or VCC connection. This can result in a glitchy reference potential. With this the reference voltage (GND) floats a little bit and can be changed or better distorted from external immissions like RF transmissions or 50Hz mains hum. The problem is, if you want to measure that, the 20pF of the oszi probe can be enough to pull anything to a "good enough" GND potential that is strong enough to fight the immissions! This were my concerns, not the bad rising edge.
We already have a much smaller Pullup of 1k-1k2. The 10k is outdated! If
That's good to know. I unscrewed mine and checked, 1011 or 1101 SMD code means ~1kohm. Good.
I got the 10k from here:
That's on the "merged" branch, and it is apparently only on the PCB (which I looked at to see what shape the traces have) but it is at 1.2k in the schematics. So a PCB update would be needed.
communication problems with other I2C devices (temp Sensor)
Well, is it possible that the problem only occurs on OBS devices with the BME/BMP sensor installed? In which case, there might be your culprit...?
Ahh yes, I didnt imported the netlist to the pcb. I have that value layer hidden most of the time. Douh!
This is just the combination of an I2C buffer AND multiple I2C devices! Just 2 or 3 more I2C devices and no buffer works fine, at least for me. But at the end, we want to integrate a temp sensor in the near future. So having more I2C members on the bus will not be a niche application.