[Hardware, Plugin] Arduino based physical display + serial port io+ tutorial (24-11-19)

[Dmitrik]

I think we would need to steal some code from mechjeb/engineer for that

Is it possible to get all that directly from engineer, without stealing code? I understand - it`s unpleasant to be dependant on others plugins, but it will save so much time.

Edited May 11, 2015 by Dmitrik

[I_KILL_HORSES]

Looks like you can just replace "numdisp" with "lc"?

I could kiss you! Thank you so much for taking your time with my problem.

Edit: deleted bad code.

Edited May 11, 2015 by I_KILL_HORSES

[zitronen]

Is it possible to get all that directly from engineer, without stealing code? I understand - it`s unpleasant to be dependant on others plugins, but it will save so much time.

Na I try to avoid that. It's hard enough trying to debug my own code and people's hardware problems over the intarwebs. If you want to do that you are more than welcome to fork the code yourself.

I could kiss you! Thank you so much for taking your time with my problem.

For anyone else who wants the same format as me, this results in a different problem. I will give an example.

Say that we want to print VData.AP in meters. We then type this:

printNumLED(0, (long)(VData.AP),' ', DEC)

With this code, the problem is that when for example AP is 1000 meters, the display will show 00001000, making it a little less pleasing to my eyes then just 1000. For the display to not show zeroes, but blank spaces instead we type:

printNumLED(0, (long)(VData.AP),' ',0);

This puts us back to square one, where the first digit of the display is left blank, permanent. My solution to these problems is to combine the two different formats.

 if (VData.AP<10000000)
    {printNumLED(0, (long)(VData.AP), ' ' );
      }
    else
      {printNumLED(0, (long)(VData.AP),' ', DEC);}

I'm pretty sure you should be using the new function she sent you, why are you still using the original one? Try

printNumLEDnew(0, (long)(VData.AP), ' ', 0, DEC)

[I_KILL_HORSES]

I'm pretty sure you should be using the new function she sent you, why are you still using the original one? Try

printNumLEDnew(0, (long)(VData.AP), ' ', 0, DEC)

Well, this is embarrasing...

[Freshmeat]

2zitronen: Hi! your plugin is awesome. I`m doing my own hardware controller too, and looks like you saved a ton of my time. I would like to make a powered landing helper, that would show me when it`s time to start suicide burn. And take-off helper, that wil show me how far I`m from terminal velocity. For those I need a TWR, or even better - current thrust and mass of a vessel. Is it possible to get that kind of data through your plugin?

I did some coding on that in my controller, in the thread linked below. Caveat is that you have to enter TWR manually. I guess you'll need the drag coeffcient of your vessel as well, as terminal velocity no longer can be simply approximated in 1.x. I will get back to look at it once examinations start.

[zitronen]

I guess you could also make a function that forces say 10% throttle for a second and measure the acceleration then multiply by 10 to get your TWR.

[Freshmeat]

I think this is the best place to ask these things: How robust is the signal from a CD4021? I want to make a separate unit for my joystick setup, and have found an old VGA cable and two connectors. This gives 13 pins to connect, so I am a bit limited. The analog signals will naturally get a line each, but my ideal setup will include more digital lines than available.

The natural solution is a shift-in IC, but the signal will have to travel about a meter and across two vga connectors, which is bound to introduce a bit noise. Is this noise enough to disturb the signal?

Edited May 17, 2015 by Freshmeat
Confused the shift-out and shift-in IC's. Doh.

[AmeliaEatyaheart]

I have of course asked Amelia for help, but due to time difference our correspondence is pretty slow. Anyone here who can help me with how and where to declare 'numdisp'?

replace 'numdisp' with 'lc' in your code - it's just the name of the displays you're using

I've PM'd you with updated code - once I'm near my hardware and can confirm it works, I'll update my dropbox, but I've sent you an advance copy in your messages

EDIT: Updated code can be found here: https://www.dropbox.com/s/ud69sks1u6z30kf/Demo_for_7segMAX7219_module_updated.zip?dl=0

Edited July 25, 2015 by AmeliaEatyaheart
Fixed some code

[zitronen]

replace 'numdisp' with 'lc' in your code - it's just the name of the displays you're using

I've PM'd you with updated code - once I'm near my hardware and can confirm it works, I'll update my dropbox, but I've sent you an advance copy in your messages

I think we got it sorted a couple of pages back. Thanks for the code.

[Mattew]

Hello everyone!

First thing, very much thanks to Zitronen for making such a amazing plugin/mod and thank to all who help make it even better. Its amazing thing, realy, I love it. And second thing, I need little help from you, experienced builders. As many of you, when i saw way of making physical control panel for ksp i simply couldnt resis and start making my own. Building stuff based on Arduino isnt something new for me so no prob here. I have my prototy build on Mega 2560 board with stuff on breadboard (prototype ). I got my 3 leds, stage button, throttle pot, graphics lcd as info panel. Well everything working well and smoth, control ok, info from ksp/plugin ok, BUT sometimes my comunication just went out from some reason. Green led go off, Tx led on Mega stop blink (Rx still blink), and all data stop go in and out. No controls, no info, nothing. Then sometimes and randomly Tx blink, green led went on, then go off again as no data come in. And weirdest thing is that sometimes I got comunication back complety so i can control/read data from ksp again. I tryed to lower bit rate from 115200 to 57600 and still same. Update rate is same (0.08). Any idea what can cause those com drops? I would love fix it and finalize my panel

PS: If this problem is somewhere discused already, just punch me in face with link, but I am sorry i couldnt fine it. And i read all! Hell of reading 99 pages, belive me

[T.A.P.O.R.]

Hi Mattew,

Welcome to the board!

I think someone else had this issue a few weeks ago.

Something to do with mismatched plugins on Page 93

Good luck!

[zitronen]

Hello everyone!

First thing, very much thanks to Zitronen for making such a amazing plugin/mod and thank to all who help make it even better. Its amazing thing, realy, I love it. And second thing, I need little help from you, experienced builders. As many of you, when i saw way of making physical control panel for ksp i simply couldnt resis and start making my own. Building stuff based on Arduino isnt something new for me so no prob here. I have my prototy build on Mega 2560 board with stuff on breadboard (prototype ). I got my 3 leds, stage button, throttle pot, graphics lcd as info panel. Well everything working well and smoth, control ok, info from ksp/plugin ok, BUT sometimes my comunication just went out from some reason. Green led go off, Tx led on Mega stop blink (Rx still blink), and all data stop go in and out. No controls, no info, nothing. Then sometimes and randomly Tx blink, green led went on, then go off again as no data come in. And weirdest thing is that sometimes I got comunication back complety so i can control/read data from ksp again. I tryed to lower bit rate from 115200 to 57600 and still same. Update rate is same (0.08). Any idea what can cause those com drops? I would love fix it and finalize my panel

PS: If this problem is somewhere discused already, just punch me in face with link, but I am sorry i couldnt fine it. And i read all! Hell of reading 99 pages, belive me

I think this might be caused by the arduino code not being able to keep up with all the data (maybe your lcd code is taking all the processing time for example), try reducing the data rate, change it to 0.2 or something.

[Mattew]

I read all from page 93 to end. But that isnt my issue since i got handshake and data. Maybe zitronen is right about code isnt able to keep up with plugin since most of time whe communication fail is during ascend or descend when game produce mist data (speed, alt and so on) But when ship orbits doing nothing then everything is fine. Most of time. when i come home i try to change refresh rate to be slower and see what happen.

[T.A.P.O.R.]

I read all from page 93 to end. But that isnt my issue since i got handshake and data. Maybe zitronen is right about code isnt able to keep up with plugin since most of time whe communication fail is during ascend or descend when game produce mist data (speed, alt and so on) But when ship orbits doing nothing then everything is fine. Most of time. when i come home i try to change refresh rate to be slower and see what happen.

If I recall correctly, I had the odd drop out and reconnect when my console was still together.

Sometimes my 7 Seg diplays would freeze up too.

Its in bits, so I can't test anything at the moment (or for a while yet).

[stibbons]

If you're getting intermittent dropouts then I'd also suggest checking your USB cable. I've had a couple of arduino boards ship with dodgy cables, that I had a hard time pushing decent transfer rates through until I changed them.

[Mattew]

So I got my testing done. Changed refresh rate in config file one by one and come to 0.2 rate, same as Zitronen suggest and it has possitive results. No more drop outs. everytihng is smooth. So far done 4 flights ground-orbit-ground a 100% of time wokring. I am guessing its realy to much time consuming calculation for GLDC. It will need some heavy optimalisation bcs at this moment, I am refreshing and redrawing everything on it with each program cycle even when nothing change at all.

Anyway, thank all for theyr suggestions and ideas. Hopefuly it ll work now and ever And when i get my prototype from breadboard to real control panel i definetly post some pictures

[T.A.P.O.R.]

If you're getting intermittent dropouts then I'd also suggest checking your USB cable. I've had a couple of arduino boards ship with dodgy cables, that I had a hard time pushing decent transfer rates through until I changed them.

My compute is ancient, may be part of the problem. No replacement until I finish studying.

[zitronen]

So I got my testing done. Changed refresh rate in config file one by one and come to 0.2 rate, same as Zitronen suggest and it has possitive results. No more drop outs. everytihng is smooth. So far done 4 flights ground-orbit-ground a 100% of time wokring. I am guessing its realy to much time consuming calculation for GLDC. It will need some heavy optimalisation bcs at this moment, I am refreshing and redrawing everything on it with each program cycle even when nothing change at all.

Anyway, thank all for theyr suggestions and ideas. Hopefuly it ll work now and ever And when i get my prototype from breadboard to real control panel i definetly post some pictures

Nice. I think what happens is if you spend too much time doing stuff the arduino's serial buffer gets filled up and you end up with incomplete packets and keep getting them until the buffer can be cleared. There's probably some ways to handle that or at least give you a warning it's happening.

[stibbons]

A big part of the problem is that the built in Arduino Serial library uses a 64 byte buffer. If it's increased to match the size of VesselData then you can get away with only polling once per refresh cycle. But because it's smaller you need to be able to poll it frequently enough to drain it while data is coming in.

I know that increasing the serial buffer size used to be very annoying. In 1.0.x versions of Arduino you need to edit library source, and then hope you haven't accidentally allocated more RAM than the Uno has. It looks to be more accessible in 1.6, but I still haven't been able to figure out how to do it nicely.

Of course, in a perfect world user code would also just get an interrupt when the receive buffer was full and could deal with it appropriately.

[Mattew]

it maybe case of overload arduino with to much work. But maybe not bcs sadly i run in com drops again and i didnt change anything. No code change or hardware change, just using my prototype. Its better then before bt still getting random drop. Even tryed change usb cable and port and same thing. Closely observing I found its completly random. Com drops during launch, deorbiting, orbital flight and work on orbit. It even happend when game is paused! I start thinks its more hardware problem related since i build it on bredboard. During testing i found when wire from push button isnt properly connected and ends "in air" arduino went crazy and block coms. When wire is connected to gnd or 5v (simulate push or release) in most cases it start working again. Disconect wire and bam, com drops. Is this can be issue? Like noise in wires bcs of not good connections on bredboard and jumpwires?

[MrBlackstone]

Zitronen,I'm having troubles making the anolog axis work with my potentiometers (pitch,yaw,roll) ,would you please show me the arduino code i can use to control axis?

In the output sheet of your demo code there is this "CPacket.Pitch = constrain(map(analogRead(PITCHPIN),PITCHDB,1024-PITCHDB,0,1515),0, 1515);",but only the throttle is working and i still cant figure out how to program and control all the others axes.Can you help me?

[Freshmeat]

Have you checked the config file? Try forcing everything to take commands only from the plugin.

Also the above line need to have subtracted half its max value to get a range to both sides.

[zitronen]

it maybe case of overload arduino with to much work. But maybe not bcs sadly i run in com drops again and i didnt change anything. No code change or hardware change, just using my prototype. Its better then before bt still getting random drop. Even tryed change usb cable and port and same thing. Closely observing I found its completly random. Com drops during launch, deorbiting, orbital flight and work on orbit. It even happend when game is paused! I start thinks its more hardware problem related since i build it on bredboard. During testing i found when wire from push button isnt properly connected and ends "in air" arduino went crazy and block coms. When wire is connected to gnd or 5v (simulate push or release) in most cases it start working again. Disconect wire and bam, com drops. Is this can be issue? Like noise in wires bcs of not good connections on bredboard and jumpwires?

Wait you have your reset pin floating?

[Mattew]

Yes i have it floating. I never connected Reset pin to anything. I read something about using capacitor on that pin to ensure correct function. I may give a try se what will happen.

Btw i have only two buttons right now. Stage button wich is using internal pull-up resistor and menu change button (switch "menus" on GLDC to show different things) that use external pull-down resisor.

EDIT: I just did test with capacitors and check wires and so on. No positive results at all. So little desperate i took prototype (with Mega) apart and build mini simple test platform based on uno. Just three leds, stage button, throttle pot. Upload code, do flights and guess what? no errors at all. All smooth all time. (for two hours of playing, we ll se later). So It ll be probably oveloaded mCU due to glcd or i dont realy know.

I probably change "theme" of panel from modern with displays and nice light buttons to more retro (apollo) era with analog meters that dont eat my mCU to dinner doing calculations

Edited June 1, 2015 by Mattew

[zitronen]

You really need to not have the reset ping floating. You can use the my schematic from my board from the first post as an example of how to wire up the reset pin correctly for serial programming.