bork_bork

That looks like you've borked the timing to the 7 seg displays. What ever you added to the main loop is taking too much processing time. - - - Updated - - - Got the panels laser cut and painted today. Happy with how they came out, but I will need to cut the upper one again. Parts are interfering on the backside of the panel.

Note that both adjusting the refresh rate and increasing the buffer did the trick for me. I'm on the Mac version of the plug-in, though. I don't know how the refresh rate works on the windows version. /BORK! - - - Updated - - - Would it be possible to add some error tracking to the arduino code to watch for serial buffer overflows? Putting in a bit of basic error handling really helped me track down the source of my connection drops.

In case anyone needs it - I've updated the maxmatrix library to write to multiple chained 7seg displays. At the moment it assumes an 8 digit display and is probably not as efficient as it could be. This is for displays utilizing the MAX7219 driver.

I did boost the serial buffer to 256. That has made a difference, at 115200 I haven't had any missed packets anymore. I had been seeing about 10/minute. I've got a variable watching the occurrences of "EF" and the number of times the function returns a true result. Counting the deltas, so far it is holding steady at Zero now.

I can't get the serial to handshake at 250000. Any tricks recommended at that speed?

I'm considering rejiggering the serial packets to only send data that has changed, to see if I can get it up to 60HZ.

Hi Stibbons - I played with the refresh value in the config.xml. By changing it down to 50hz (0.02), I've got a nice responsive system now. I think it was sending at over 100hz by default.

Hey folks - I'm using the mac version of the library and arduino code. I've been having quite a bit of trouble with the serial ports. I've been watching the number of good decoded packets, vs the number discarded. The number of discarded packets is 5x higher than the number decoded. It looks like I'm only getting about 1 good packet per second. Using serial ports at 115200 on a ATMEGA 2560. Has anyone run into similar issue?

Very nice, thanks guys!

Is it possible to read the state of SAS / Brakes, etc? I would like to display current state and have button for toggle, rather than a switch. In the current code I only see inputs for SAS, etc.

So - the answer to the checksum fails was buffer overruns. The 20ms taken to drive the display was too much. I have re-written the display driver and got it down to 3ms. No more buffer overruns and no more checksum fails! Thanks everyone for the help! A great debugging tip to anyone out there seeing similar: Put a check at the top of KSPBoardReceiveData to see if available bytes is > 62 and light up pin 13 to show the error.

So, I did a bit more testing. I am getting massive checksum fails on packets. Only 1 out of hundreds of packets passes checksum. That explains why the display felt very 'laggy'. Now to debug why I am getting so many checksum failures. This is with KSPDemo9 running at 115200. I was unable to get KSPDemo10 to read anything from the serial port yet. I am running an ATMega2560. /bork

I am running a driver for 7 segment displays based on the MAX7219 (MaxMatrix library). I have tested that in a tight loop and get sub 10ms update times, so I don't expect that to be a problem, but I can try disabling it and see if that improves the update rate. I'll also wire up only the simple LED for SAS and see how that goes.

Marzubus - thanks for putting together this port. I put it on my Mega2560 with a MacBookPro. I am noticing very slow refresh to my arduino and auto-detect is not working. If I set no-detect I get data to the arduino. This is with serial running at 115200, which should be more than sufficient. Is there a method to debug the Serial Port detect handshake? EDIT: After reading through a few previous posts, I may be hitting the 32bit struct padding issue. Has anyone else already solved that and can share code? /bork