m365_dashboard
m365_dashboard copied to clipboard
augisbud
Freezes once in a while
The Arduino freezes once in awhile it only seems to be happening with my hard driving so right now I think it's trying to open the menu because there is no speed check for that but that doesn't always seem to be the case. Anyone else experienced something similar?
I'm starting to think that the issue is with the library, gonna change it to the Adafruit library and maybe create a separate github for testing purposes 😕
Try out this This is the beta branch, it might contain bugs, but worth checking out, it uses a U8G2 library so download it before.
Hi ! I'm running your sketch on my m365, and it crashes every 30s. I have another arduino on the same 5V source next to the batteries that i'll remove soon. I've started to think that the arduino pro mini must crash when it's running on like 4V. So maybe the solution is to put a big capacitor on the power line to avoid this ? I'll try it soon, but if you do it first, fell free to let us know ;)
Well I have discovered that it seems like the bus overflows, because everytime i spin the tire in the air from 5km/h to 30km/h(custom firmware), the speedo freezes and sometimes catches back on
Oh, ok.. So maybe the solution may be to add an interruption timer that starts before every serial.read ? Then you can flush the serial port if it freezes by doing something like that if i remember : void flushSerial(){ while(Serial.available () > 0){ Serial.read(); } }
Or, maybe the best solution is to use Serial.onReceive(stockInATabFunction); that triggers on every serial event ? then in the dataFSM(), you can just check if there is something waiting in the tab
Hmmm, It freezes because it receives too much data so a millis() delay could help it
But a delay is not a solution, so having something like you mentioned could work better
brake and throttle value filter seems to help for someone on youtube, any ideas ?
oh and it makes sense, because it's spamming the same values and it overflows
I have no idea, but can you give us the link to that video please ? i've also seen that some days, instead of freezing, it could work just nicely.. Btw, how have you found out that it is an overflow error ? Thanks !
It's kinda an overflow, even the xiaomi mi app freezes if you put the scooter in the air and press the throttle fully
Hi, thanks for sharing that project. Did you tried with pro mini 3.3v ?
You will destroy it, the rail is 5v, a capacitor or some kind of regulator.
Uhmm, heat? the uno is good for 12 volts too, but it's actually made for 5v
I agree that 12v requires a heatsink but the electric scooter regulator range is 0 to 5.5-6v max
For me it happend one time, i drive with this software over a week (60km). Maybe it depends of arduino, ther are so many manufactors?
Mine freezes every 1km approximatively.. I dont really know why because when i put the scooter in the air and press the throttle fully nothing more than the "normal" 1km freeze occurs.. I'm trying to add a second "watchdog arduino" to see if i can fix it that way
of course i have deleted the bootup part to skip the animation ^^. I'll tell you if it can kind of fix it
Check if the percentage drops after sometime, because sometimes only the speedo freezes
no it doesnt unfortunately.. everything stops even the percentage.. (infinite power i gess ?? 👍 )
and for me :-)
All scooter hang up, and stop driving, all led are off, and the display was on and suspended showed the speed.
hey guys i've figured out that when the port crashes, the arduino is still alive and working ! https://photos.app.goo.gl/jfD18F17mBE4PSTo9 On this video you can see that the screen is frozen and the arduino is still working (i've made the led on port 13 blink for debug)
I see something like this sometimes (long time ago), when i drive with phone on bluetooth, my speed on mihome app freezes. I am not sure if this is not a coincidence, but often helped by tapping on a platform or passing through bumps or holes on the way :smiley:
I've finally fixed it with my second watchdog arduino.
Actually, when the arduino freezes due to a serial overflow, the 13th pin starts to blink pretty fast, and you cant reset it via the reset pin. You have to physically turn it off and on.
That's why i'm now doing that.
I'll release my fix tomorrow i think, it only costs the price of a second arduino nano.
It's not the best solution but at least.. it works ^^ https://github.com/tibzejoker/m365_dashboard
Hi all, I’m waiting for a new oled screen to test it out since I broke mine :p but... There is a command for serial that checks for an overflow, and another for flush the serial, so... what if you put this piece of code at the very begging of the loop() function?
if(XIAOMI_PORT.overflow()) { XIAOMI_PORT.flush(); }
Sorry if there are errors but I’m writing from the phone. Will be working also to find a software based solution! :)
of course i have deleted the bootup part to skip the animation ^^. how did you do it??
of course i have deleted the bootup part to skip the animation ^^. how did you do it??
display.setFont(m365); displayClear(0, true); display.setCursor(0, 0); display.print((char)0x20);
remove this.
if(XIAOMI_PORT.overflow()) { XIAOMI_PORT.flush(); }
It seems that overflow function it's defined in serial software library and not defined in serial hardware library so can't be used in our case :(
I found this topic https://arduino.stackexchange.com/questions/19078/hardwareserial-check-for-overflow/19085 don't know if it can be useful
I have idea, but i can't test it, because my display dont hang up ( i cant do fast that 30km/h on my engine)
Check 172 line of define.h Speed can't be integer, because integer is to max 32,768 (32,7km/h). It has to be unsigned int or long.
Test if that helps?
Ok. I know why, but I do not know how to improve it :(
The speed in queries is sent in the form FF FF (integer max32768 = 32.768km/h).
Therefore, when we cross the speed, the display freezes, the similar happens with the mihome application (Confirmed). https://imgur.com/gallery/6rlEi5Q
Apparently the application on the phone "m365 tools" shows the higher speed, but in this I do not have 100% confidence. https://imgur.com/gallery/gl4PbXO Maybe they use another query for speed?
It is possible that the query changes if we cross the barrier 32768 or damage in some way.
It would be nice to know what the query looks like at a higher speed, it can just change the amount of data, and with our code they are set permanently.
You could try to read the speed from another query, but I'm not sure if it's possible. There are another queries contains speed, but i don't now if this helps, or try to stop reading speed(queries) when it is too high?
Something like that happens with Arduino when we cross the variable limit https://imgur.com/gallery/r9HgHd5
I think that you could use our usb-to-ttl and see what happens on the line BUS? When this bug is happening.
Unfortunately, I do not have such possibilities because my scooter does not accelerate to this speed, but I will try to work with the Botox Software generator and set other parameters :wink:
In my case the freezing has nothing to do with going faster than 30 km/h, I'm on stock firmware 1.4.0 and can't go faster than 25 km/h
Check your connections too. I've had the display freezing because of vibrations when testing with dupont connectors
i make test code to calculate speed over 32.7, maybe this will help the screen not freezing.
Can anyone test it? https://github.com/lukaszlukasz0/m365_dashboard
i make test code to calculate speed over 32.7, maybe this will help the screen not freezing.
Can anyone test it? https://github.com/lukaszlukasz0/m365_dashboard
i need your opinion but i think it should look something like this
struct __attribute__((packed))A23CB0 {
//32 bytes;
unsigned char u1[10];
int16_t speed; // /1000
unsigned int averageSpeed; // /1000
unsigned long mileageTotal; // /1000
unsigned int mileageCurrent; // /100
unsigned int elapsedPowerOnTime; //time from power on, in seconds
int mainframeTemp; // /10
unsigned char u2[8];
} S23CB0;
m365_info.sph = (double)((double)S23CB0.speed / 1000.0);
all of this is based of https://github.com/heardrwt/Xiaomi-M365-Display/blob/master/ninebot_module.c line 247
Int16_t don't change anything, int is 16 bit too.
On the Arduino Uno (and other ATmega based boards) an int stores a 16-bit (2-byte) value. This yields a range of -32,768 to 32,767 (minimum value of -2^15 and a maximum value of (2^15) - 1). Source: https://www.arduino.cc/reference/en/language/variables/data-types/int/
yes, i have read that yesterday, but i checked out other sources and everyone is using that
maybe they use other processors that normally use int_32.
Speed https://imgur.com/gallery/57RGf1M
Check this pic, smartinick make display https://github.com/smartinick/esp32_xiaomi_m365
m365_info.sph = (double)((double)S23CB0.speed / 1000.0);
why do you assign the variable unsigned int to float (double)?
Ps. Double in atmega are the same as float.
to store speed like 39km/h and etc we need a 32bit integer like in java
int32_t is the same as long, can store negatives numbers, range from -2,147,483,647 to 2,147,483,647 unsigned long is the same as uint32_t,can't store negative number, range from 0 to 2,147,483,647
struct __attribute__((packed))A23CB0 {
//32 bytes;
unsigned char u1[10];
long speed; // /1000
unsigned int averageSpeed; // /1000
unsigned long mileageTotal; // /1000
unsigned int mileageCurrent; // /100
unsigned int elapsedPowerOnTime; //time from power on, in seconds
int mainframeTemp; // /10
unsigned char u2[8];
} S23CB0;
unsigned long sph;
m365_info.sph = abs(S23CB0.speed) / 1000L); // speed
I think :-)
long speed; // /1000 You can't do this, because speed from controller are in 16bit signed integer, not 32.
You need to take it in this format.
unsigned long sph; m365_info.sph = abs(S23CB0.speed) / 1000L); // speed
Here is don't matter, because unsigned int is sufficient to store speed to 65km/h, becaause before we do abs() on him.
Here is telegram where smartinick said that https://t.me/joinchat/H_JWIFCSCRZPRPp_71tRAg&ved=2ahUKEwiWm-KknKzeAhWrBcAKHRUBB0cQjjgwAHoECAYQAQ&usg=AOvVaw2NTzqG1ArxRyrgbqFdQrk1
And he is here too XiaomiM365Hacking https://t.me/XiaomiM365Hacking
Ok, can you send me that telegram chat? You may be actually right, because when i had the raw format from the scooter set to long i wasn't getting a reading
view last post :-)
Do you have access to saved data from the bus? Can you send it?
There is some such clean data here, but there is probably nothing about speed in them. https://github.com/smartinick/esp32_xiaomi_m365
good day, I have a plea. i have downloaded SW for display on m365 here from the site. The arduine version is 1.8.5. When compiling, it writes an error. C: \ Users \ kiki \ Desktop \ display \ M365 \ M365 \ M365.ino: In function 'void displayFSM ()':
C: \ Users \ kiki \ Desktop \ M365 \ M365 \ M365.ino: 421: 24: warning: switch condition has type bool [-Wswitch-bool]
switch (WheelSize) {
^ you can load into arduin, but in M365 the display will freeze and help reset. Thanks in advance for your help ...
The project occupies 19526 bytes (63%) of the storage space for the program. Maximum is 30720 bytes. Global variables occupy 715 bytes (34%) of dynamic memory, 1333 bytes remain for local variables. Maximum is 2048 bytes.
I've finally fixed it with my second watchdog arduino. Actually, when the arduino freezes due to a serial overflow, the 13th pin starts to blink pretty fast, and you cant reset it via the reset pin. You have to physically turn it off and on. That's why i'm now doing that. I'll release my fix tomorrow i think, it only costs the price of a second arduino nano.
I know this is an older reply, but I can't figure out what you're supposed to do with the nano for your fork, and you don't have issues enabled on your repository page :(. I'm willing to deal with an older fork if it fixes the freezing issue.
Same here, I tried to get the physical watchdog going. I added the missing defines so that the code seems to be complete, but when I connect it like on the diagram display doesnt work. Can you please provide the fully working solution? Many thanks!
Hi, I probably found why the screen freezes. When I started the screen at the test stage, everything was fine, I drove about 30km and no one got stuck. When everything was assembled and the arduino put the case in the scooter, and I chose the thinner screen wires, the screen stuck immediately after the ride. When I disassembled - everything worked again. Choosing thicker wires to the screen - the screen just got stuck sometimes.
I found such a thing that: The screen works with the I2C signal. When you extend the screen wires, thinner or longer. That is long for I2C. It means that the SDA and the SCL may cause noise and SDA and SCL. That's the least influence on each other. A single wire for the SDA and a single wire for SCL free, but that would work. I have got some timeouts, but it is not full proof against I2C bus errors. I have seen a number of propositions in the library yet. The I2C is also designed to be used in a pcb board.
Need to install either arduino on the screen or look for some other solution like "Pull-up resistor" on LCD...? Here's an example of how I just freeze the screen with just a touch. https://drive.google.com/open?id=1naDs08Jd8gVpxAuW47bFvRbOPc9G6R5D
That would explain why it freezes a bunch on heavy regenerative braking - electrical noise. I wonder if
A: a ferrite bead or similar on the power lines would help, and
B: Putting the display right on the arduino with the shortest lines possible would help
I think B would be the answer, I'm thinking of attaching an led to see when it's the arduino overflowing, and when it's an i2c bus error
Or another option: C - Pull-up resistor. I used "pull-up resistors". It is recommended to use the 4,7k resistor to amplify the I2C signal. I added a 5,6k resistor (only I had) from the screen power (VCC) on each SCL and SDA signal.
Even after collecting everything and driving already 40Km, the screen doesn't get stuck... Even though the arduino is far from the screen.
Pull-up resistors help with the screen freezing, but do not help with the freezing every 30 seconds/1km. Anybody fix this? It's really bad, and when mine freezes it takes the scooter with it and I lose all throttle until I reset.
I've noticed when it freezes, the battery controller board blinks a green LED labeled D2. It also blinks this LED when the dashboard is disconnected after being powered on, so this mod is crashing the dashboard itself.
Pull-up resistors help with the screen freezing, but do not help with the freezing every 30 seconds/1km. Anybody fix this? It's really bad, and when mine freezes it takes the scooter with it and I lose all throttle until I reset.
I've noticed when it freezes, the battery controller board blinks a green LED labeled D2. It also blinks this LED when the dashboard is disconnected after being powered on, so this mod is crashing the dashboard itself.
does it freeze for you every 30seconds/1km without the resistors?
Hi guys, i don't have the m365 yet, but i'm waiting for it and assembling this LCD, do you have tried to add a simple LC filter to the Arduino power line, like these 1A or 3A ones used in the FPV systems? I got some Arduino projects with coils (relays and motors) that freezes the Arduino (including the watchDog) when the coils are disconected (EMF noise). In mostly cases an LC filter solved de problem.
This is not a clean power issue, it's a software issue. This software was stolen from another non-github user, who has since fixed the freezing issue (has to do with unsigned integers) and sells this product on their own webpage.
Ohh, ok. On this case the LC don't solve the issue.... but are you sure the watchDog hangs for an overflow or similar?
I dont have freezes, since I properly soldered the display connections. Had an hour long ride just last week with no problems at all.
This freezes only display or also scooter? Lately randomly Im experiencing both freezing and I have to reboot scooter.
Hi. It freezes only in Big spidometer mode. Maybe you want to delete or fix it? And also can you add remaining mileage?
How can i test it before soldering the cables to the scooter? Should it report bus data is missing? I am asking because i tried to power it and the screen remains black... Any help would be appreciated
it should power up showing bus error,maybe you have a bad connection somewhere or bad oled
I fixed it. I removed the lines refering to spi screen libraries
Did you fixed? or not? If you did it, can you make a pull request or explain what did you changed on the code please?
Thanks!
Sorry for the delayed precense but i am abroad and i have limited time. I have fixed the black screen issue that some peaple including me are facing (i believe it was related to the i2c vs spi libraries selection-at least in my case-since it is working now) replace these lines from original "defines.h" in order to use it with i2c screen (sorry i am a noob- it is the original code corrected where the compiler gave me an error and now the screen works fine.)
#include "WatchDog.h"
//#define DISPLAY_I2C
//#define US_Version
//ifdef DISPLAY_I2C #include "SSD1306AsciiWire.h"
#include "fonts/m365.h" #if Language == RU #include "fonts/System5x7ru.h" #else #include "fonts/System5x7mod.h" #endif #include "fonts/stdNumb.h" #include "fonts/bigNumb.h"
#include <EEPROM.h>
#include "language.h" #include "messages.h"
MessagesClass Message;
const uint16_t LONG_PRESS = 2000; uint8_t warnBatteryPercent = 5;
bool autoBig = true; uint8_t bigMode = 0; bool bigWarn = true;
bool Settings = false; bool ShowBattInfo = false; bool M365Settings = false;
uint8_t menuPos = 0; uint8_t sMenuPos = 0;
bool cfgCruise = false; bool cfgTailight = false; uint8_t cfgKERS = 0;
volatile uint8_t oldBrakeVal = -1; volatile uint8_t oldThrottleVal = -1; volatile bool btnPressed = false; bool bAlarm = false;
uint32_t timer = 0;
//ifdef DISPLAY_I2C SSD1306AsciiWire display;
bool WheelSize = true; //whell 8,5"
uint8_t WDTcounts = 0; void(* resetFunc) (void) = 0;
(i have made minor corrections so that my screen would work but the code is the original and not mine :)))
Has anybody found a solution for the freezing, without second arduino as watchdog?
Hi can you converting this project SSD1306AsciiWire library to adafruitssd1306.h library or u8glib or u8g2lib
To be honest personally i do not have the knowledge to do it... It requires a lot of reading...and i do not have the time, this reriod... But why you want to do this? It works pretty well this way
Witajcie. Wyeliminowałem zawieszanie się dodając rezystor 120ohm na linii data pomiędzy płytka m365 a Arduino. Do tej pory zawieszała się co chwilę , oraz silnik czasami jakby się wyłączał . Dzisiaj rano przejechałem 5 km bez żadnego błędu.
Witajcie. Wyeliminowałem zawieszanie się dodając rezystor 120ohm na linii data pomiędzy płytka m365 a Arduino. Do tej pory zawieszała się co chwilę , oraz silnik czasami jakby się wyłączał . Dzisiaj rano przejechałem 5 km bez żadnego błędu.
Have you also had the screen freeze on the speed reading?
today I drove about 15km and the meter worked perfectly. never hung.
today I drove about 15km and the meter worked perfectly. never hung.
thanks, I will try this method too.
There is no concrete solution. I replaced the resistors with other values, as advised in similar projects, and the Arduino still freezes. It can run for a few days without freezes, and then still hang.
Has anyone a look at the data signal with an oszi? Maybe the signal is not good enough. But I think there is an code bug too, because freezing should not happen if the data could not be read. Maybe something with interrupt. Now I will start to have a look on the code.
I can’t turn on the headlights with this item meter. I wonder if everyone has the same problem?
Glad to release the v 0.B version (B means Bruno). A improved software watchdog is in place. Never freezed in some months of heavy use, at high speed and neither on hard braking. Made the necessary corrections to made the code work on pro's version (now can display current speed, or real time current value) cause these models, unlike the classic m365, have another ble protocol. No more crashing when tyre is spinning. Works fine on almost every 5V Arduino board, even all those who integrate a Serial TTL that could interferes with bus, Half Duplex is now reached by SoftwareSerial(). Tested on Xiaomi Scooter Essential, Xiaomi PRO 2 and Mi Scooter 3. Also works in combination with CamiBLE 075 v 10. You can find the project on my Github home.
Glad to release the v 0.B version (B means Bruno). A improved software watchdog is in place. Never freezed in some months of heavy use, at high speed and neither on hard braking. Made the necessary corrections to made the code work on pro's version (now can display current speed, or real time current value) cause these models, unlike the classic m365, have another ble protocol. No more crashing when tyre is spinning. Works fine on almost every 5V Arduino board, even all those who integrate a Serial TTL that could interferes with bus, Half Duplex is now reached by SoftwareSerial(). Tested on Xiaomi Scooter Essential, Xiaomi PRO 2 and Mi Scooter 3. Also works in combination with CamiBLE 075 v 10. You can find the project on my Github home.
Could you give a link?
Im hard working to make it cheaper, easier and more affordable... even more useful than commercial version of “M365 dash”. To achieve a good result I need some more days to refine my project. Next week two versions will be released : Ninebot compatible; Xiaomi compatible;
Im glad to share with you my project, fully compatible with multiple scooter versions. Neat dash, test release by Bruno. Available on https://github.com/Dubstaaa/NeatDash-