search

gpstar81 / GPStar-proton-pack

GPStar Proton Pack and Neutrona Wand
https://www.gpstartechnologies.com
GNU General Public License v3.0
39 stars 9 forks source link

New system modes, updated menu system #200

Closed gpstar81 closed 1 year ago

gpstar81 commented 1 year ago

-New system modes: Super Hero and Mode Original. -Updated menu systems with ability to adjust smoke, over heat timings, system default volume, etc. -Updated various sound effects, wand barrel extension sound effect.

Refer to the operation guide for more information.

nomakewan commented 1 year ago

Please note I've opened #201 which corrects some random stuf in the updates branch I've noticed. Give it a look and see if it might be worth merging before merging this one.

EDIT: Thanks! Can't wait to see this one out in the wild!

DustinGrau commented 1 year ago

So far the code looks good, nothing really standing out to me on paper. The doc updates are significant and I am more than happy to condense into a "field guide" later--though for now I've contributed some edits to make the menu tables more concise. I have my pack and wand updated and have been focused on testing the actual behavior since I didn't spot anything obvious in the code. For sake of noting the one issue found so far, when playing a music track any attempts to navigate to the next track results in that playing on top of the previous track. This occurs for both the wand menu and the attenuator API.

nomakewan commented 1 year ago

That is because musicNextTrack() changes the value of i_current_music_track before calling stopMusic(). stopMusic() should be called before changing i_current_music_track so that the currently-playing track will be stopped prior to switching tracks (as-is stopMusic instead tries to stop the next track, which isn't playing yet).

EDIT: musicPrevTrack() has the same bug.

DustinGrau commented 1 year ago

Thank you, that resolves the track navigation via next/previous. Confirmed with wand, and both Attenuator models (Nano and ESP). I also confirmed that the adjustments to the Attenuator code in this branch maintains communication with the pack.

DustinGrau commented 1 year ago

The next issue I'm encountering is only an impact to the new Attenuator code and API's. If I put the pack into Mode Original I will get the API notification of the change. However, if I power down at the battery that information does not get sent to the Attenuator after all devices boot up. Similarly, I do not get the count of music tracks. These feel linked in that the initial handshake/sync event is not happening and the values are not being sent. Unplugging and plugging the serial device back in after the pack is powered doesn't seem to resolve it (Attenuator still sees the mode as "Super Hero" which is the device default).

Any chance you could just take a quick look on the pack side to see if anything might be blocking that initial sync when the device is connected? Would it be worth adding a "A_SERIAL_RESYNC" call just to tell the pack to re-send all of it's state information?

gpstar81 commented 1 year ago

The next issue I'm encountering is only an impact to the new Attenuator code and API's. If I put the pack into Mode Original I will get the API notification of the change. However, if I power down at the battery that information does not get sent to the Attenuator after all devices boot up. Similarly, I do not get the count of music tracks. These feel linked in that the initial handshake/sync event is not happening and the values are not being sent. Unplugging and plugging the serial device back in after the pack is powered doesn't seem to resolve it (Attenuator still sees the mode as "Super Hero" which is the device default).

Any chance you could just take a quick look on the pack side to see if anything might be blocking that initial sync when the device is connected? Would it be worth adding a "A_SERIAL_RESYNC" call just to tell the pack to re-send all of it's state information?

Ok I will hook up a nano board to test right now.

DustinGrau commented 1 year ago

I'll need to test further after this evening when I have more time. I did a quick check with my ESP controller and was getting some odd behavior. I'd like to try again with the Nano and the current codebase to see if it's something in my newer code.

gpstar81 commented 1 year ago

I'll need to test further after this evening when I have more time. I did a quick check with my ESP controller and was getting some odd behavior. I'd like to try again with the Nano and the current codebase to see if it's something in my newer code.

Fyi I changed the handshake to a a_sync_start, which is probably what's causing the behaviour for you on the esp32. Change the sync start to match what I did for the changes in the nano attenuator code and you will probably be ok.

DustinGrau commented 1 year ago

Ah, I see it now. Shouldn't take long to merge and check with the new hardware to confirm later.

DustinGrau commented 1 year ago

Merged to the Attenuator code, old and new, and Tx to the device is restored and I'm getting all the data updates. However, now the API calls being sent back to the pack are not being received. I've debugged up to the point where the struct object is sent but didn't get far with debugging the pack side. I think it has something to do with the b_serial1_connected never getting set to true.

gpstar81 commented 1 year ago

Merged to the Attenuator code, old and new, and Tx to the device is restored and I'm getting all the data updates. However, now the API calls being sent back to the pack are not being received. I've debugged up to the point where the struct object is sent but didn't get far with debugging the pack side. I think it has something to do with the b_serial1_connected never getting set to true.

Hmmm I will take a look again today.

gpstar81 commented 1 year ago

Merged to the Attenuator code, old and new, and Tx to the device is restored and I'm getting all the data updates. However, now the API calls being sent back to the pack are not being received. I've debugged up to the point where the struct object is sent but didn't get far with debugging the pack side. I think it has something to do with the b_serial1_connected never getting set to true.

I made some changes to the serial 1 connection in this now. Check out the updated Attenuator ATmega328P code to see whats going on now. Particularly the loop() and waiting for the pack, it is now no longer pinging the pack during startup but instead waits for a pack response. Then a sync happens. Added flags as well to prevent serial protocol spamming. This one works for me and gets out of the waiting for pack state and gets into the mainLoop() to do it's regular thing.

DustinGrau commented 1 year ago

Whoohoo! Everything works beautifully now. I was able to hot-swap the new ESP device for a Nano running the older Attenuator software and it didn't skip a beat. Everything sync'd up and began working as expected. I'd say that wraps up the new functionality--it's good to go and we can work on the next things from this new base software :)

gpstar81 commented 1 year ago

Whoohoo! Everything works beautifully now. I was able to hot-swap the new ESP device for a Nano running the older Attenuator software and it didn't skip a beat. Everything sync'd up and began working as expected. I'd say that wraps up the new functionality--it's good to go and we can work on the next things from this new base software :)

Ok, I just did a rebuild of the firmware. If you think it's ready, give it a merge.