ryan00793

It's not hard to compile c# if you have visual studio installed.

Are you using genuine arduino's or things ordered off amazon / ebay? Yes arduino's are connected via a usb cable but there are some issues that I'll outline below that make a usb ttl adapter needed. A usb ttl adapter is basically a usb thing that converts usb commands into serial commands which allows you to control an arduino. All arduinos have one built in but a driver issue makes the genuine arduino not work correctly on Win10 so the question above actually matters in this case because most ebay / amazon ones tend to use what's cheaper since they're selling it for cheaper, however in this case the cheaper usb to serial adapter works better. So you're bypassing the bulit in arduino usb serial adapter for a cheaper one that works with win 10.

@zitronen The update with out that change seems to be much more reliable at launch for me thanks for the update. @Mattew If you want a version that works with the latest version of serialIO you can look at my fork. (pending PR to the main project)

@KingLuxor I found a bug, just posting here incase you have github notifications turned off. The bug is basically that you hard coded the refresh rate into the timer at half a second. In the issue on github you can find a fix for the code (only one line so I didn't make a pull request). Link to github issue I've made a PR for the fix the next update of serialIO. (turns out that you can't just make a PR and then push a change to your own fork with out it getting included into the PR)

@zitronen My bad I thought for some reason that the uno had an 8Mhz cpu. Also thanks for pointing out that it's explained in the first post. @Mattew That link I included shows that the refresh rate is actually hard coded. You can just replace that line with what's below to make it not hard coded (watch the rx light on your arduino to confirm). I've now made an issue on the repo with it so that the guy can fix it. _udTimer = new Timer {Interval = (int)(refreshrate * 1000)}; However it's kinda weird since it works at a faster rate than what I have in game, and maybe it's because it's the same data??? But I just saw the update I'll try it and see if that fixes my issue.

There is a work around posted not too long ago where Mattew posted that a different serial chip will make it work since it's not using the arduino chips. Work around here That's frankly disappointing I bought the mega hoping it would be "better" 16Mhz vs 8Mhz but I guess it doesn't directly translate to performance. That tool doesn't actually change refresh rate as seen here I can update it but I don't exactly know what the refresh rate number represents. If no one actually knows I can just open an issue on github and be like "WHY IT NO WORKKK?" I'm using a modified one of 13 i think? But the actual thing works it's just as mattew said i guess going to fast.

I got most of my parts finally and should probably start really looking at my design again since it's starting to look like it's getting close to time to figure out how I'm really gonna pull it off. I've decided that I'm going to work with the current screens I've got and figure out what I want to do about two joysticks (pitch roll and yaw VS forward backward side to side [RCS]) but I've also got to work through issues with my mega (goto the serial io thread). @richfilesHave you thought about using tlc5940NT (pwm multiplexer (kinda)) for your leds? (also how are you controlling the brightness if not hardware pwm).

So I just got a mega 2560 and I seem to be having an issue with reliability. For example I'm finding that I'm having issues getting it to "sync" up at launch or on a resume. And by sync up I mean that I'm getting issues where the wrong data is displayed and doesn't update at all (I would occasionally get this on an uno but very rarely and pressing the reset button on the arduino uno fixed it [reset doesn't fix on mega 2560]) on launch but when resuming from the tracking station it has a different issue (didn't notice this on the uno) but it has the correct data sometimes but other wise the data is static (might have updating data for a minute or two). Both arduinos are using the same code so I don't really understand what's the deal. I am using win 10 but the mega I got has a ch340g (looks identical to the ch340g on the uno).

@richfiles Yea on mine you can see the diode on the back so I knew it was gonna be a problem (about the same drop for me as well), it's why you can see the two vcc and ground going elsewhere (doesn't have to be done with ground but I ripped two wires off of the bundle so I just went with bringing ground back as well). However I can't chain them like you are they just don't work well after the second display and maybe that's because I'm not using the real SPI bus but idk, I'm still waiting for the mega in the mail so maybe with a mega I might be able to better drive them off of random pins (I'm just using an unoR3 atm (I don't know if the higher clock speed on the mega means higher switching freq on the pins but maybe?)). Just saw the edit. thanks for that, I have some tlc5940nt's (5) for controlling the rgb leds I'm going to drop in the box if I do it. I'm kinda liking the idea of having the rgb leds near the switches as well so idk if I'm going to do both.

I would rather stretch it out and keep all the displays over removing some for the labels (size isn't set in stone it's just there to give an idea of what I was shooting for) just looking for creative solutions to the problem. Mine don't have an spi bus so they can use w.e. (ish (In practice I've noticed that they tend to fall out of sync and lock or stop displaying numbers when CS isn't on pwm)). I can indeed make it taller and just space it out a bit more but I was looking to see if there was any more creative ways to do it. For example moving the scale leds or just using one rgb with different colors or even different lay out of the screens where the leds are on one side and labels on the other. Also good thinking about monitors since I wasn't, I also plan to have a switch / button panel on the bottom with fun stuff like a slider and switches and ofc key locks with big red buttons. Basically what do you guys think of that layout? Should I change it to look different should I nix the annunciator box and go with something like those tft screens (real ones)? Idk it's all up in the air and I'm doing this for fun so I don't mind having to get a better tool for the job if I feel that it's worth the money. For example these 7-seg displays i think were just north of $1.50 each so it's not the end of the world if someones like hey you don't need that many and should do XYZ instead. PS 3 of the 9 7 seg displays I ordered were faulty so I would need to order 3 more anyway to get back upto 9, so atm I have 6 and I could just order more since the guy is gonna refund the costs of the 3. Just poking around to see what you guys think design wise.

So I've started my project since I've started to receive parts however I've not decided on a full design yet my current thinking was the pic below but there isn't enough room for me to label each display. So what do you guys think I should do?

What drivers did you use (I just ordered the module that you linked)

Why would kRPC be different that say serialIO, it just looks like a c# api to read / write data. Unless you're saying that I would need to write my own communication library to talk with an arduino...

I'm looking to start to get into making a panel but i want to make sure it works on windows 10 first since I have windows 10. Also a known good example .ino for the arduino wouldn't go amiss.