MS2/Extra 3.4.2 CAN speed/delay - error in manual

[Talkiet]

Hi all - me, AGAIN, but making lots of progress towards full CAN logging on Teensy integrated with tyre temp monitoring and GPS timing.

I now have the simplified Dash broadcasting getting valid data into my Teensy, however it's got a HUGE delay - something like 2.5-3 seconds between pushing the throttle and seeing the TPS and RPM rise accordingly. I have seen videos on youtube that show near instantaneous updates, so I am wondering if my ECU (MS2/Extra 3.4.2) is likely the cause of the issue, or my programming. Is anyone able to confirm whether I should be able to get near realtime (less than 200ms) reads of the simplified dash broadcasting (IDs 1512+).

Also, while reading the manuals I found a very small error in this doc. http://www.msextra.com/doc/pdf/Megasqui ... adcast.pdf

The example message at the end of section 1.1 shows Engine RPM as Data bytes 2 and 3, while it should be 'EGOcor1'.

I am knocking together the smallest possible program to read just one value from the dash broadcasting (or will configure the realtime data broadcast to just send one item, maybe 2, TPS and RPM) and display to an LCD. What sort of latency/delay should I be aiming for? (Using a Teensy 3.5 for what it's worth)

Cheers - N

[grom_e30]

sounds like its your code that's the problem. post it up here for people to have a peek

[Talkiet]

Yeah, it's the code - when I ripped out the CANbus stuff and put it in a little sketch by itself it seems to be fine. I'll have to dive into the spaghetti tomorrow - there is heaps of optimisations working around the incredible slowness of I2C displays so lots of the code is only conditionally visited once every so often (every x passes or every y milliseconds for example). Clearly I have managed to put part of the CANbus stuff in a slow loop.

If I have no luck with it after sleeping on it and looking in the morning I'll see if I can post up the offending code but realistically now I know the hardware is capable I'll just chuck in a heap of checkpoints in the code and see where it's on a go slow

Learning so much about the MS and working around the pretty thin resources on most Arduinos in the last couple of weeks!

Cheers _ N

[grom_e30]

when i did my can display i used metro so the screen was only updated every so often as my code was initially updating the screen every loop and this caused me to miss loads of can data as the loop was slowed down for the screen writes. after using the metro so the screen was only updated every so often it was much better

[Talkiet]

Just to close the loop on this - I moved my 'CANread' function call to the main loop so it's called every time instead of once every 100ms synced with the GPS position processing. This worked perfectly.

Even reading CAN and reading 16 x MLX90614 temp sensors and doing some work to test for GPS position crossing a finish line and logging to SD< I am still only using about 30ms of the ~100ms I have if I want to maintain 10Hz GPS which is great. I was prepared to drop to 5Hz GPS but staying at 10 is a bonus!

Although it's not particularly interesting (car is not on track), here's a video I just did today to functionally test much of the system. (Front left temps are missing and front right are having issues. Rear tyre temp sensors are sitting in passenger seat until I get a mount sorted. Spees is from GPS, all other data is from the MS via CAN.

There's a terrible inset video of the in car display screen (20x4 LCD) which is actually very readable in person.

http://www.youtube.com/watch?v=B3tQ3kWmuTU

Nest up I have to add a brake sensor (or better yet a brake pressure sensor ) and hook that into an ADC on the MS. It's annoying the MS2 doesn't have a VSS input so I don't have to worry about syncing it from GPS but so far the GPS and CAN data seem to be pretty consistent.

Cheers - N

ps. I have an HMI display arriving in a few days so will start work on making a pretty digital dash with all the data then.