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

[Mattew]

So I looked on data packets Arduino recive and send using serial port monitoring program. I am not sure but I found something little weird looking to me, but maybe it is normal. 

This is basicly RECIVED PACKED (Vessel Data?) how it looks. 

Spoiler

 BE EF C8 01 BB F9 FE 47 77 24 FB 47 E3 1D 32 49   ľďČ.»ůţGw$űGă.2I
 D9 1D 32 49 07 B8 39 40 A1 4A B0 3A 5C AA B7 3D   Ů.2I.¸9@ˇJ°:\Ş·=
 75 79 CB 39 4B 02 00 00 5D 06 00 00 2A D2 AF 3F   uyË9K...]...*ŇŻ?
 00 00 00 00 23 08 00 00 57 AE FC 47 57 AE FC 47   ....#...W®üGW®üG
 6E 82 F8 44 A6 E9 AF 3D 69 C6 8E 40 0E 55 E0 46   n‚řD¦éŻ=iĆŽ@.UŕF
 0E 55 E0 46 89 17 09 47 89 17 09 47 00 94 13 46   .UŕF‰..G‰..G.”.F
 5E 82 13 46 00 18 8D 45 13 2B 76 45 00 00 00 00   ^‚.F..ŤE.+vE....
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
 00 00 00 00 0E AD 41 46 0E AD 41 46 11 B7 6C 46   .....­AF.­AF.·lF
 11 B7 6C 46 4E 16 02 00 8F C2 F5 3D D4 8B 09 45   .·lFN...ŹÂő=Ô‹.E
 00 00 00 00 00 00 00 00 E0 00 7F C2 30 A9 D3 C1   ........ŕ.Â0©ÓÁ
 E8 D8 A6 43 00 00 82 15 00 00 00 00 00 00 00 00   čئC..‚.........
 07 07 00 00 00 00 00 00 00 00 10 A4               ...........¤
 

Nothing unsual for my noob eyes  And we know data recive work in way how it is supposed to work.

But This is how SEND PACKET (Control Data?) looks like.

Spoiler

 BE EF 2D 65 C1 00 02 00 00 00 01 00 00 00 00 00   ľď-eÁ...........
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
 00 00 00 00 00 00 00 00 96 01 00 00 00 00 00 00   ........–.......
 1D BE EF 2D 65 C1 00 02 00 00 00 01 00 00 00 00   .ľď-eÁ..........
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
 00 00 00 00 00 00 00 00 00 98 01 00 00 00 00 00   ...............
 00 13 BE EF 2D 65 C1 00 02 00 00 00 01 00 00 00   ..ľď-eÁ.........
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
 00 00 00 00 00 00 00 00 00 00 97 01 00 00 00 00   ..........—.....
 00 00 1C BE EF 2D 65 C1 00 02 00 00 00 01 00 00   ...ľď-eÁ........
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
 00 00 00                                          ...
 

What I find weird is fact it look like almost no data is stored in it and it looks like its repeat four times with sligh diferences. That is right or its some bug?

Its realy weird that plugin can send data and arduino recive data and sucesfuly read it but can send data or send data in correct fromat so plugin dont recive anything/ read anything. I out of ideas what to try to do with my limited COM comunation knowledge

[zitronen]

That looks correct?

Each packet starts with "0xBE 0xEF". The control packet is shorter and is sent more frequently it will only have a lot stuff in it if you are using lots of switches and axes.

[Mattew]

False alert then, both packets are correct?  If so, why then no controls are taken from control packet. Stupid question, do we have way to see what plugin recived, like what was in control packet, final decoded data?

[zitronen]

Since I don't have windows 10, I can't check myself right now, but I remember we made debug versions to check what's going on. Basically nothing is received, the receive event never fires.

[Benji]

6 hours ago, zitronen said:

Since I don't have windows 10, I can't check myself right now, but I remember we made debug versions to check what's going on. Basically nothing is received, the receive event never fires.

 

So the CH340-Chipset isn't the only Win10 problem. Even with non-failed handshake nothing gets through.

@zitronen: Can you please compile a 0.18.6-debug-version, so we Win10 idiots people can do some "testing"?

[c4ooo]

With all the people who are sending keystrokes to the computer via an arduino emulating a keyboard, perhaps a control byte could be added that would designate a single key that the plugin would then press. I am sure .net has an equivalent of the Java robot class.

Edited December 12, 2016 by c4ooo

[zitronen]

15 hours ago, Benji said:

 

So the CH340-Chipset isn't the only Win10 problem. Even with non-failed handshake nothing gets through.

@zitronen: Can you please compile a 0.18.6-debug-version, so we Win10 idiots people can do some "testing"?

Huh? Did this just start happening all of a sudden?

[Mattew]

To be honest, probably yes, it did. My situation: Last week i took my Due, starts programing and it magicly start talking to your plugin with no issues (execpt no controls) using Atmega16U2 but it didnt work in past like that! So i try comunicate using ch340 to see if it fix no control problem, but no succes.  Still no controls. I am not sure why it not works now since when looking at serial analyzer, pc definetly reciving data but for whatever reason it dont get to ksp.

If I got time I ll try to setup test UNO or MEGA with latest demo to see if I can some controls out of it.

I ll try to go lower baudrate and refresh rate to see if there is some changes.  Also little something to add. For whatever reason i see "mini disconnects" like it lost connection for 0,5 sec then resume. It happends every like 4-5 sec. Even when code is almost stock with no changes. Buffer increases are in place 

[Benji]

(Nearly-)Similar to Mattew: I used a Mega. And after not getting a connection

-I also tried a Serial-USB Adapter-thingy, CH340-

Last week, I thought I'll try out a Due.

With the Due I get a connection, getting Data from KSP, can print it on the LCD Panel. But the Data I send from Due to KSP is not affecting anything.

 

But unlike Mattew I seem not to be affected by "mini disconnects".

[Freakout242]

Hi everyone,

         Finnaly got my shipment of goodies today!!! (LCD Screens, New LEDs, and a Analog Meter). I decided to start with my Analog meter to show the fuel depletion. I was reading post from and to @Mulbin on page 3, 

and got to writing. I do not have a 15v gauge like he started with. From what I see using the fade sketch, my meter will read from 1 to 10 before it pegs out. I defined the gauge as FUELG, 6 and did a simple analogWrite to the utilities tab. analogWrite(FUELG, map(VData.LiquidFuel, 0, 1, 0, 10));     I also made sure I set FUELG to OUTPUT. Now here is the strange thing.....the needle moves but only when the fuel is either at 25% or I go full throttle. Then it pegs out. If I hit the Z and X key, I can make the needle dance. Any ideas?

 

Edited December 12, 2016 by Freakout242

[Freakout242]

13 minutes ago, Freakout242 said:

Hi everyone,

         Finnaly got my shipment of goodies today!!! (LCD Screens, New LEDs, and a Analog Meter). I decided to start with my Analog meter to show the fuel depletion. I was reading post from and to @Mulbin on page 3, 

and got to writing. I do not have a 15v gauge like he started with. From what I see using the fade sketch, my meter will read from 1 to 10 before it pegs out. I defined the gauge as FUELG, 6 and did a simple analogWrite to the utilities tab. analogWrite(FUELG, map(VData.LiquidFuel, 0, 1, 0, 10));     I also made sure I set FUELG to OUTPUT. Now here is the strange thing.....the needle moves but only when the fuel is either at 25% or I go full throttle. Then it pegs out. If I hit the Z and X key, I can make the needle dance. Any ideas?

 

ok...ok....I'm not thinking tonight. I forgot to take out the Caution Yellow LED statements which were also on pin 6. I also change the analogWrite Statement to analogWrite(FUELG, map(VData.LiquidFuel, 0, 100, 0, 10));

 

[Mattew]

I would like to hear more from other ppl if they also have no control issue.  And those mini disconnects probably is some issue on my end, not pluggin I ll look into that later  If I got time I do some testing with uno today as I said. Still preparing for that

@Freakout242 if u do not plan use any of original pinouts in demo I do recomend delete all statements and lines of code that use them. Clean code for your use.

[zitronen]

16 hours ago, Freakout242 said:

ok...ok....I'm not thinking tonight. I forgot to take out the Caution Yellow LED statements which were also on pin 6. I also change the analogWrite Statement to analogWrite(FUELG, map(VData.LiquidFuel, 0, 100, 0, 10));

 

Can you show us what kind of meter it is? Is it a volt meter or amp meter?

4 hours ago, Mattew said:

I would like to hear more from other ppl if they also have no control issue.  And those mini disconnects probably is some issue on my end, not pluggin I ll look into that later  If I got time I do some testing with uno today as I said. Still preparing for that

@Freakout242 if u do not plan use any of original pinouts in demo I do recomend delete all statements and lines of code that use them. Clean code for your use.

I'll have some time this weekend to make a debug version for you to test.

[Mattew]

That would be awesome! Thanks.

Got my UNO tests done and here are result:  It is working without CH340 module using on board Atmega16U2. Data recived, data send, Controls are working (analog and digital) with no problem. Then I switched to Due. Data recived, data probably send (judging by blinking TX led on Due board) but no action in KSP (not on analog input or digital input) taken. Nothing happen at all. I am out of ideas

[zitronen]

What... Have you been drinking or taking drugs?

[Mattew]

Why I should? No,but my processors apparently do

Edited December 14, 2016 by Mattew

[Freshmeat]

While we are at it, I have a randomly occurring bug: Ever so often, my analogue input goes the way of the Dodo. The plugin register that something is happening, because it turns off SAS when I pull the stick, but pitch/yaw/roll controls do not change. A scene change makes the problem go away. Nothing in logs. I am running 18.3 on a win 7 64-bit, with a Mega in the other end.

It has been happening for some versions, I have just not gotten around to reporting because the bug rarely is annoying, and very difficult to give good input for. A debug version of the plugin might give an indication of what is wrong. However, I have not that much time to play atm, so it has absolutely no rush.

[Benji]

On 13.12.2016 at 5:38 PM, Mattew said:

That would be awesome! Thanks.

Got my UNO tests done and here are result:  It is working without CH340 module using on board Atmega16U2. Data recived, data send, Controls are working (analog and digital) with no problem. Then I switched to Due. Data recived, data probably send (judging by blinking TX led on Due board) but no action in KSP (not on analog input or digital input) taken. Nothing happen at all. I am out of ideas

 

I'm beginning to take this personally (...you Arduino-Win10-Driver-Whatever-Situation).

Once I was nearly finished with my prjoect using a MEGA, I (okai, my fault there) switched to Win10.

Then I started to use some CH240 USB-TTL Converter. First it worked, suddenly stopped. Then I gave the DUE a chance. It worked once (it did send hardcoded throttle), then stopped suddenly.

Now your UNO seems to work with onboard USB and your DUE doesn't?

 

I'm tempted giving the MEGA another run.

[Freakout242]

On 12/13/2016 at 4:20 PM, zitronen said:

Can you show us what kind of meter it is? Is it a volt meter or amp meter?

I'll have some time this weekend to make a debug version for you to test.

Here is the link for the Meter I am using

http://www.allelectronics.com/item/pmd-100ua/100-ua-dc-panel-meter/1.html

If I write analogWrite (FUELG, 9);  it pegs the meter out. It's showing .21 Volts from my Multi-Meter. So that would mean that I need to drop the 5V from the arduino down to .21 volts... Correct?

 

[stibbons]

2 minutes ago, Freakout242 said:

Here is the link for the Meter I am using

http://www.allelectronics.com/item/pmd-100ua/100-ua-dc-panel-meter/1.html

You're using a meter that measures current. The "analogue" pins on the Arduino board output a variable voltage. My electrical engineering uni courses were too long ago to suggest a better way of fixing it than "buy a volt meter".

[gremlinWrangler]

Simple method to convert a current meter to volts, assuming it's a 5V Arduino and the meter movement is a perfect zero ohms. Target pegging meter current is 0.0001 A

Ohms law says R = Voltage/Current

R= 5V/0.0001A

R= 50 000

4= 50k

Don't have the table handy but think the nearest standard size is 47K, which will mean the needle may peg a bit early, then again we probably don't have a perfect 5V drive and the meter resistance will be adding as well. If it's not quite right change resistance or put a trim pot in there as well.

Since all analog meters are actually current devices you can normally convert any meter into any other sort of meter by changing resistor values around/moving shunts so if you find a cool looking coil meters for the right price you can probably convert it to Arduino drive without too much trouble unless it's a truly massive mains voltage device designed to have serious currents directly driven through it with no series resistor.

[Freakout242]

33 minutes ago, stibbons said:

You're using a meter that measures current. The "analogue" pins on the Arduino board output a variable voltage. My electrical engineering uni courses were too long ago to suggest a better way of fixing it than "buy a volt meter".

Thanks everyone, I figured it all out. I placed the meter between (2) 22k Ohms resistors. That got the output voltage of .24 volts when I write the pin to 255. Here is how I declared the statement.

analogWrite(FUELG, map(VData.LiquidFuelS/VData.LiquidFuelTotS*100, 0, 100, 0, 255));

 

[Benji]

I must say: I am really amazed.

I was just doing some "stupid" test with hardcoded outputs:

    if (millis() % 1000 <= 500){
      MainControls(SAS, HIGH);
      CPacket.Throttle = 1000;
    }
     else{
      MainControls(SAS, LOW);
      CPacket.Throttle = 800;
     }

Wow. The Mega works just fine without the CH340 hidding him from the computer.

 

I think I will use the MEGA for the communication with the pc and set the DUE via Serial1 behind the MEGA to do some fancy TFT Monitor stuff.

[Mattew]

I kind of ditch that idea of one processor for communication and second to do all stuff after seeing how it is complicated to send more then one value and I dont even mention if you wanna bi-directional communication. Plus DUE have problems to act as Slave on SPI, so be aware of that if u plan to use it  Still think that Due problem is based on to be 32b processor. Why? Bcs of this:

UNO - Stock Demo16 Sketch: 8-bit, Handshake => Yes , Data send by plugin -> Data recived => Yes , Data send by processor -> Data recived by plugin => Yes

Due - Stock Demo16 Sketch : 32-bit, Handshake => Yes, Data send by plugin -> Data recived => Yes , Data send by processor -> Data recived by plugin => No, By all clues (TX led blinking, Serial port monitor showing data packet comming correctly to USB) Due is transmiting. When and where data get lost, idk.

See my point? That only Major diference is in processor itself and fact it isnt 8b. 

 

[zitronen]

what is going guys... Has anyone tested the Due on windows 7/8 just to rule out some kind of 32 bit issue?

It could be caused by the new KSP update or a recent windows update or something.

 

4 hours ago, Freakout242 said:

Thanks everyone, I figured it all out. I placed the meter between (2) 22k Ohms resistors. That got the output voltage of .24 volts when I write the pin to 255. Here is how I declared the statement.

analogWrite(FUELG, map(VData.LiquidFuelS/VData.LiquidFuelTotS*100, 0, 100, 0, 255));

 

You can use a trim pot to get the meter scale correctly if you don't have exactly 50k resistors like @gremlinWrangler suggested.

Edited December 17, 2016 by zitronen