New Eggtimer Proton Firmware - 1.02N

After several months of testing and in conjunction with our policy of continuous product improvement, we've now released a new version of the Eggtimer Proton firmware. It incorporates a number of enhancements and fixes, including:

* You can now calibrate the accelerometer vertically while on the pad. This prevents the annoyance in which you forget to calibrate it horizontally and have to take it off the pad or lower the rail to do it. (Yes, it annoyed us too...)

* Airstarts can now be triggered by motor burnout, up to six of them. We don't expect anybody to build a seven-stage rocket to take advantage of it, but if you wanted to you could.

* Delays for both Drogue and Airstarts have been lengthened to 30 seconds, by request.

* A bug that occasionally reset the processor when you connected to the WiFi after landing has been fixed.

* Burnout metrics are now included on the Flight Summary page, and burnout event markers are now on the Flight Detail page.

* If you test-fire the Airstart channel and it's clustered to other channels, all of them will now fire properly.

* Displaying a Flight Summary after a baro-only vacuum test will no longer cause a reset.

* Some ambiguities and inconsistencies in the documentation have been fixed.

* There have been some general fixes in stability of the web pages.

You can download the software on the Eggtimer Rocketry web site,

http://eggtimerrocketry.com/eggtimer-proton-support/

To flash it, you'll need the ubiquitous Eggtimer USB-Serial cable, and a special tool... a small paperclip bent into a "U". The instructions for doing it are in the Eggtimer Proton User's Guide 1.02Q, which you should also download while you're at it, along with the Release Notes.

Note: We have updated the version to 1.02Q (from 1.02N), fixing a few issues that have cropped up, and adding a redirect to the home Status Page from the Calibration and the various Settings pages, so that a browser refresh won't resubmit them. Please download and apply the new version, thanks.

As usual, thanks for all your support!

Cris Erving, Eggtimer Rocketry

 

My two Protons just got much more useful.

 

This is very good. Mine seemed to lose it's calibration on the way out to the pad a couple of times and I didn't realize it until it was vertical.

cheers - mark

 

Yeah, I know. Sometimes when you design something what you think is going to work out really doesn't... the horizontal accelerometer calibration was definitely one of those cases. I did it that way originally because it eliminating having to factor in the tilt angle, but the reality is that the difference in vertical acceleration due to rod/rail tilt is almost insignificant, and any minor loss of accuracy is hugely outweighed by the convenience of having the offset calculated automatically when you arm the rocket on the pad.

 

Cris, I built my first proton and as (bad) luck would have it, I did NOT get the accelerometer chip perfectly aligned on the board before soldering (despite your excellent instructions advising that the alignment was critical). I was going to compensate for this by mounting the board inside the ebay at a very slight angle from vertical (about 2 degrees or so) to ensure the chip was pointed straight up. Will this "calibrate while on the pad" feature compensate for that misalignment so that I don't need to fuss? Or should I still make sure the board is mounted so the chip is aligned?

 

Two degrees isn't going to make much difference, I wouldn't lose any sleep over it. The error would be less than 0.1%.

 

Cris, question - does this resolve the issue where the page that's loaded after calibrating the accelerometer is what triggers the calibration? I had issues where it would accidentally recalibrate itself because I reloaded that page, and then I'd have to lower the rocket to horizontal and re-calibrate again. I know it could be partially solved by just using the new vertical calibration, but it would be nice if it just recalibrated and then took you back to the home page, instead of something that *looks* like the home page but will recalibrate the accelerometer if reloaded. Other than that small issue (though it did cost me like an hour at the pad trying to diagnose it) I've loved my Proton!

 

I found the same problem, and finally figured out to stop refreshing the page in order to see the new value when upright.
I wasn't sure if was really a browser issue (iPhone) rather than a Proton issue.

 

When you select the vertical calibration it simply ignores the accelerometer figure in the Status Page so it won't keep you from arming. It's calibrated automatically when you arm it. No chance of it making you re-calibrate... even if you disarm it, it will recalibrate when you re-arm.

 

Are you using the Private mode? I strongly recommend it... otherwise it may cache pages and cause issues. We DO set the "no cache" option in the HTML header, but not all browsers honor it. We also recommend that you don't use the Back button, too.

 

Can confirm it's an issue with the Proton - reproduced it on both my Android phone and my laptop (the latter once I was off the field), on a number of different browsers - Chrome and Firefox on the Android, and Chrome, Firefox, and Edge (eww) on the laptop, both with and without the equivalent private browsing mode. The issue is that the page that's loaded after calibration isn't the same URL as the regular home page, and when loaded causes the altimeter to calibrate itself, so when you reload from that page, it resets the calibration on the accelerometer. The vertical calibration option seems like a good temporary fix, but I'd like to be able to do the (probably more accurate) horizontal calibration without this issue in the future (honestly just having it redirect back to the main home page after recalibrating would be the easiest fix).

 

I just ran a horizontal calibration on 1.02N, when I clicked the Calibrate button it went right back to the Status Page, with the Accel value at 0.00, as designed. It was the "normal" URL... 192.168.4.1. Honestly, I haven't seen the issue that you're speaking of... what was the URL in the address bar? I CAN make it go back to the calibration page by clicking on the Back arrow, but as I mentioned earlier I don't recommend using the Back arrow.

 

OK, so you're back on the page where it reads zero. Now put the Proton 'upright' and refresh the browser. I like to do this to see it at ~1 before arming.
And it recalibrates it, incorrectly, every single time.

 

Just did it from 1.02N on my iPhone... I got the status page and 1.00 for Accel after hitting the browser refresh button. Let me get out my Android tablet and try it from that.

 

I don't have my proton firmware updated yet.

 

OK, I see what it's doing. It's because when you hit the refresh button it sends the same URL as before, but the server code "knows" that you want the status page because you're done with the calibration, so it displays that. The problem is that the old parameters are being executed before the page is displayed, which is why it's messing up the calibration. I'll fix it... for now, I recommend that you refresh the Status Page by clicking the ARM button instead... that's actually what's been recommended all along.

 

Thanks! Yeah, the URL I'm getting is 192.168.4.1/calib?acco=1 which recalibrates the accelerometer. I've attached a screenshot of what I'm seeing just in case it's different from what you found.

 

That's the URL that the server in the Proton sends to the client when you select the horizontal calibration option, when the Proton reads it from the client it processes the calibration then goes to the Status Page. If you keep hitting the refresh button on your browser it's going to keep resubmitting the last URL, it's client-agnostic so it doesn't know that it should not allow that URL to be processed. What I will probably do is to force a redirect to the URL of the Status Page after the calibration page has been processed (or any of the other pages that terminate in the Status Page, for that matter).

 

Yeah, that's what I figured the problem and solution would be. Simple enough to diagnose and solve, but pretty darn frustrating when you accidentally reset your accelerometer while on the pad. Thanks!

 

Coded the redirect fix today, will do a bit more testing and repost it when it's ready. I also fixed a few minor bugs, and made one change that I should have done all along... when you change the mode of a channel it will automatically go to the settings screen for the new mode.

 

We have updated the Proton's software version to 1.02Q (from 1.02N), adding a redirect to the home Status Page from the Calibration and the various Settings pages, so that a browser refresh won't resubmit them. Also, when you change a channel's mode it automatically goes to the settings page for that mode, with the defaults brought in. Please download and apply the new version from http://eggtimerrocketry.com/eggtimer-proton-support/ , thanks again for your support.

 

I updated my Proton and tested out the refresh-redirect fix. It works! Hurray. Many thanks.

I'm always thrilled when the flash update works. I do a little jig when it's done. It's my Flash Dance.

 

I just updated to 1.02Q and my biggest problem was the COM port numbers. Mine was set to 5
Had go into device manager and change it. I tried to do it in the batch file but couldn't find where it was listed.

 

I changed the .BAT to COM3 with notepad.

esptool.exe -vv -cd ck -cb 115200 -cp COM3 -ca 0x00000 -cf proton_1_02Q.bin

 

What a feeling !

 

I flew my Proton today with the 1.02Q firmware.
It worked but, with a bit of stubbornness...
I tried to arm it while on the pad. I typed the arm code and it kept refreshing with a new code.
I then, went and calibrated it with "on the Pad calibrate + 3 degrees for launch angle.
Typed in the Arm code after and it took.
Was it because I needed to re-calibrate for on the pad or because of Android auto-fill logic filled with previous arm codes?

It worked perfectly once I got past the Arm code hangup.

 

Did you calibrate it first? My guess is that you didn't... if not, that's OK, just calibrate it with the "On the Pad" mode and you'll be able to arm it just fine. I was seriously thinking about removing the calibration options entirely and making it just do it on the pad automatically when you arm it... however, then the launch angle parameter would be required. Feedback?...

 

What would be the consequences if you just assumed an angle of zero unless overridden and just auto calibrated every time? I assume it would mostly affect the accelerometer based altitude but not apogee detection? You could still offer the option to modify the launch angle. I get why you are requiring calibrating every time but to me it seems to unnecessarily complicate its usage.


Tony

 

Your accelerometer reading will be off by about 1% for every degree that you're off, as long as you're off less than about 10 degrees. In most cases, honestly, it doesn't really matter. It's not going to affect burnout detection, and apogee detection is done barometrically so it doesn't affect that either.

 

No.
The launch angle was probably more like 5-7 degrees but I didn't measure it.
I don't have any video of the flight but, it worked as expected.