Select to expand quote
boardsurfr said..
You may also want to double-check that you are loading the correct firmware. If the wrong firmware is loaded, it may look like everything is fine, but the units appear to freeze on some screens. I just had that happen after downloading and compiling the current firmware, and not realizing that the 5.72 sources on Github have the M10 chips set as the default, without checking if that is indeed the case.
To Jan: when supporting multiple chips that require different initialization or baud rates, it becomes essential to verify that the communication works as expected. For example, the firmware should check if it receives the "ACK" messages after setting anything. That way, it should be possible to automatically figure out the chip type and the correct baud rate.
Good one! I just flashed some new screens to the latest firmware (before connecting anything). I will connect some M10 chips but of you use still the older M8 ones (BN180, BN220, BN280) you need to comment out the 6th line in the Rto5.h:
#define UBLOX_M10 //indien ublox M10 wordt gebruikt, andere ublox init nodig !!!
into
//#define UBLOX_M10 //indien ublox M10 wordt gebruikt, andere ublox init nodig !!!
In the Ubloc.ccp it will check if this parameter is defined, otherwise it will use the M8 initialization.
It would definately be nice if the firmware would switch between the various gps chips, baudrates and epaper-screens instead of loading different bin files.