-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bar graph code / execution #25
Comments
I got this working, mostly . It turned out to be a couple of things:
Two other small issues I'm hoping you can help with....
|
Glad you got it figured out. Bad solder joints can kill you with this project. My pack is down at the moment due to a bad connection somewhere but I have not traced it down yet. I'm going to have to resolder each pin which is a pain while it's in the pack. The sx1509 is a handy for the job but it is an old solution now. There are several options now for led breakout boards that utilize higher voltages as well as higher current to make the leds brighter. That said you can try removing the resisters from the bar graph. This is going to cause the bar graph to pull the most current available from the sx1509 but it shouldn't be an issue. my eyes are sensitive to led light so I prefer them more muted but I also set the level for a safe current from the breakout board. I know others have gone without the resistors and been happy. |
Indeed. Sorry to hear about your pack fault -- they can be a bugger to track down, particularly when things look fine and they are not. I also fixed the issue where the bar graph didn't turn off when turning the safety back off. This required adding a call to "shutdown_leds()" in the safety off code: // if the safety is switched off play the click track If you were doing the bar graph today, what solutions would you look at? Perhaps I'll update this in my version. I also considered swapping the nano for a mega and running the graph directly, but I'm interested to hear of solutions you would consider since you have so much experience with this. |
When I started the project I intended to use a nano in the wand and a nano in the pack to run the major bits separately. As time ran down and the issues came up (length of the cable to the wand and communication cross talk issues) I had to figure out a quick solution. I was still a bit limited by the size of my son's pack but in hind sight switching to the mega in the pack would have been such a better plan. The main problem you will have is the sheer number of wires running from the pack to the wand if you go with the mega. If I were doing that I would stick the mega in the wand if there is enough space as fewer wires would go to the pack then. Still the length is going to be a problem with communication and cross talk as these are low voltage devices. It was one of the things that kept me doing a breakout board in the wand. I'll need to look but I saw a new breakout board on adafruit I think for doing single arduino pin to many non-controlled led's not too long ago. I'll post back here when I find it but it looked like a really good option |
If I didn't have the lever-pop mechanism going into the wand it might be possible to get a Mega in there. Unfortunately, getting a bit tight between switch wiring and the lever-pop mechanicals. Was that this board you're thinking of? https://www.adafruit.com/product/1427 With the Mega in the pack, if I were controlling the bar graph with it, I'd need to run 3 ethernet cables from the pack to the wand. Possible, but starting to get tight I think. What were the main issues. you had with crosstalk on long cable runs? Perhaps this is something I can anticipate and get ahead of.... |
Yeah that is the board I was thinking about as it's 5v and can run off the same source as the arduino. It would be the same 3 wires needing to go to the sx1509 as well if you were to go that way. It's just a newer design and 5v which makes things easier. The biggest issue I had was controlling the audio fx board from the arduino in the wand. Debugging, the cross talk was causing gibberish on the arduino side when trying to read the fx board. Never had any issues with the led stuff but running the control arduino in the wand was a no go. I tried all kinds of different wires to see if I could find shielding that would make it work. Nope. Then I ran out of time and just made the decision to put the arduino in the pack and be done with it. |
I'm going to order the board and give it a try. I also see that there are some bare chips that could be useful in minimizing circuit size, like the TLC5917 LED driver. Might try both and see where I end up. I'll post back here if useful. Any time I've used long wires in Arduino projects I end up needing to debounce in code, else I get errant information at the other end. I've never been able to solve it electrically although I'm sure there are some things that could be done there as well (I just do not know them yet :) I think I'll still switch from the Nano to the Mega for the pack, though I likely won't drive the whole bar graph from this alone, instead opting for the SX1509 or one of the above solutions if they prove capable. The Mega will just leave more options in the future for other modes, and there is plenty of room for it. Appreciate all your discussion -- it's extremely useful. Cheers. |
yeah, debouncing works for standard pin communication but in the case of the audio board and the sx-1509 we're talking about serial communication. It was literally coming in as gobldegook and I was able to find the length at which I got valid data but it was no where near as long as it needed to be. I started to think about switching to wireless communication or bluetooth between the boards in the wand and pack but then I would have needed separate power sources for the pack and wand. In the end what we came up with works and there are numerous people that have done the bar graph in the wand and I don't believe they have had comms issues with the sx1509 at that distance. Maybe the lower voltage helps there? dunno. Could have also been issues with the arduino I was using as they are knock offs. There is a lot more capability and power in the mega so a lot of the issues I had may be a non issue for you. |
Ah, I see, your issues were between the Arduino and Adafruit FX board. I'm not sure how to go about solving those, I wonder if there is electronically a cleaner way, I do not know. It would be an interesting rabbit hole to go into. A wireless solution would be fun to implement. I suppose you could run a 12V rail down to the thrower to power the wireless device and step it down with a buck converter as needed. The SX1509 is a solid solution and it works. I'm intrigued by some of the LED driver chips which might make for a nice package if I do a small custom PCB for the bar graph itself. |
Hello there ! Thanks for the great work, instructions and sharing for this project. |
That's awesome, your kids will be stoked. I know mine still wants to play with it all the time and he's 11 now. I'm sure there are lots of possible substitutions out there for components. If you come up with code that works using the new hardware you can fork this repo and update it with your changes. I can add it as an available fork with different hardware components for others to look at from the main description page |
Eric, Did you have any joy with the Afterlife code please?You were going to let me have a copy of were you are at please.RegardsChris Sent from Samsung Mobile on O2
-------- Original message --------From: Eric Banker ***@***.***> Date: 09/02/2022 17:49 (GMT+00:00) To: CountDeMonet/ArduinoProtonPack ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [CountDeMonet/ArduinoProtonPack] Bar graph code / execution (Issue #25)
That's awesome, your kids will be stoked. I know mine still wants to play with it all the time and he's 11 now.
I'm sure there are lots of possible substitutions out there for components. If you come up with code that works using the new hardware you can fork this repo and update it with your changes. I can forward people to it for options.
—Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Chris, that wasn't me who had modified the code for the afterlife cyclotron. I forget who it was but the post was in response to you in the thread |
Ok thank you. I will try the old thread many thanksSent from Samsung Mobile on O2
-------- Original message --------From: Eric Banker ***@***.***> Date: 09/02/2022 22:39 (GMT+00:00) To: CountDeMonet/ArduinoProtonPack ***@***.***> Cc: chris-smith20161 ***@***.***>, Comment ***@***.***> Subject: Re: [CountDeMonet/ArduinoProtonPack] Bar graph code / execution (Issue #25)
Chris, that wasn't me who had modified the code for the afterlife cyclotron. I forget who it was but the post was in response to you in the thread
—Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you commented.Message ID: ***@***.***>
|
@CountDeMonet I'll try to do that, I'm noob to Github and can't quite grasp the architecture yet. It's hard to fit STL to my requirements, by any chance, no pushing, are your models pieces available in STEP or Fusion 360 ? No pushing, just asking... |
The files I used were modified from existing stl's and custom made files I did using 3d Builder. Some I have 3mf files for but most only in stl. |
Ok you are really patient because trying to modify stl with precision is a pain in the ass! I think that I'm gonna redo the main gunbox in Fusion 360 to fit my hardware... |
Greetings!
Having some trouble getting the barograph code to work....
I believe I have everything wired correctly and double-checked the solder joints.
It works fine with the "neutrona_wand" file with no barograph. As soon as I upload the barograph code, nothing works.
I tried to comment out these lines to see if there was some problem initializing the SX1509:
// Call io.begin(
) to initialize the SX1509. If it// successfully communicates, it'll return 1.
if (!io.begin(SX1509_ADDRESS)) {
while (1) ; // If we fail to communicate, loop forever for now but it would be nice to warn the user somehow
}
However, even with these lines commented, the code ceases to function.
Any thoughts on what's going on here?
The text was updated successfully, but these errors were encountered: