New Eggfinder LCD Software Release

We've just released a new version of the software for the Eggfinder LCD receiver that address a few issues with the LCD-GPS Module:

o An issue with some received GPS packets being skipped due to excessive internal processing with the LCD-GPS Module code has been fixed. GPS packets should now be processed and displayed about once per second regardless of whether or not you have the LCD-GPS Module, or which screen you're in.

o If you recall a saved location (by pressing the button during the "Waiting for Fix" screen), you can now navigate to that location by pressing the button; the LCD-GPS navigation screen will be displayed and will update according to your current location in real time. This allows you to navigate to a saved location exactly the way that you'd navigate to a "live" location.

You can download the update from https://www.eggtimerrocketry.com/page29.php

As usual, thanks for your continued support!

Cris Erving
Eggtimer Rocketry

Ok, time to go updating time again. Could that problem been in the firmware before the external GPS unit came out? If so, that might have added to the latency issues I think I'm having with a tracking program (APRSISCE/32) I've been using that was missing painting
rocket positions on a map. I think one problem is I have to run "two" instances off the application, one listening to the rocket and one instance that is monitoring the local position and "transmits" the local position through an internal network once
every 10 seconds to the 1st instance so rocket and local positions can be painted on the same map. I was thinking the 1st instance was dropping rocket positions while "listening" on the network port for the local position.

I was going to eliminate this problem by shutting off networking in the 1st instance that is monitoring the rocket position so it's not "listening" for the local position. I just have to click on a switch to shut it off. When the rocket has landed, I can turn the switch on and
get the local position painted on the map and get the rocket.

Why all this trouble? The program has the potential for bread crumbing the positions with altitudes posted next to the positions.

Xastir does it even better. It posts the lat/long/alt/bearing right next to the positions on the map and one can pull up a very readable list of all the positions received. Can save everything to various logs .kml or otherwise. Unfortunately requires a Linux laptop
but has some of the finest data presentation and storage I've seen.

I tried to get Xastir running on an Android platform using the XSDL server and Gnuroot Debian. Unfortunately, Xastir cannot connect up or see any Bluetooth connected devices on Android for a fixed variety of reasons I shan't bore you with. Close but no cigar. Kurt

Worked for me .. Thanks Cris !

Also thanks for the replacement Quantum component I lost .. !

Kenny

Sent from my LG-LS997 using Rocketry Forum mobile app

ksaves2 said:

Could that problem been in the firmware before the external GPS unit came out?

Click to expand...

No, it wasn't a problem before the LCD-GPS code was added because there wasn't a second serial port and GPS trying to compete for the CPU's fairly limited resources. In fact, if you had the 1.10r firmware release and did NOT have the LCD-GPS, it acted exactly the same as before... you got a beep almost every second to signify that the receiver decoded a packet. With the LCD-GPS module added, there "sometimes" wasn't enough time to decode and process the rocket's GPS data before another packet came in. We fixed this by disabling the LCD-GPS' serial port and interrupts until we're ready to read a packet from it. With that change, virtually every GPS packet from your rocket gets decoded in real time, and the worst case scenario is that you'll lose a packet once every 10 seconds while we read the internal GPS instead.

Thanks. I'll diddle with running one instance of my tracking program and see if I can recover more positions.
Kurt

Updated! Cris, on one of my flights with the last version (with the LCD Rx's GPS installed) my LCD stopped showing rocket position updates shortly after launch & never started up again. Could that be because of your first bullet? Other rockets worked fine and that rocket has tested fine on the bench since then. Sorry, but I don't remember exactly what the LCD was doing except that the rocket position was stale.

Thanks!

Damn it! I just updated to 1.10r yesterday. Oh well. At least the procedure is still fresh in my memory.


Sent from my iPhone using Rocketry Forum

BDB said:

Damn it! I just updated to 1.10r yesterday. Oh well. At least the procedure is still fresh in my memory.

Click to expand...

I always forget the step of putting everything in c:\eggtimer instead of my downloads folder.

Me to self: "Why can't it find the hex file?? It's right there!?

<4 tries later>

Oh. The directory's wrong. Look, it works."

GrouchoDuke said:

I always forget the step of putting everything in c:\eggtimer instead of my downloads folder.

Me to self: "Why can't it find the hex file?? It's right there!?

<4 tries later>

Oh. The directory's wrong. Look, it works."

Click to expand...

LOL. This was me last night:

“Damn it. Why can’t I ever remember DOS commands? How do I change the stupid directory?”

Google....Google....Google....mutter....mutter....mutter.....”Is that a forward slash or a backslash?”

“Oh look, Cris wrote the exact command in the directions! I’m an idiot.”


Sent from my iPhone using Rocketry Forum

I just updated mine this evening without any issues and I am looking forward to field testing. So far the LCD in the new Black Aero case with the BT module and GPS has assembled as advertised, which in itself is satisfying.

I am curious as to how well the GPS tracking is without the need for a phone. Having said that my intention is to use the LCD connected to my phone via BT, unless the battery has died in which case I will use the integrated GPS as my back-up.

mpitfield said:

I am curious as to how well the GPS tracking is without the need for a phone. Having said that my intention is to use the LCD connected to my phone via BT, unless the battery has died in which case I will use the integrated GPS as my back-up.

Click to expand...

You'll be amazed how easy it is... trust me. You'll end up using your phone as the backup.

No problems with my update. Thanks Cris.

Updating to 1_10r took 20 tries to get it right. Super excited that 1_11b worked great the first try. Thanks for all the great support Cris. Looking forward to receiving another box from you.

Will my incoming LCD have the new update installed?

Hey Cris,

I would like to have the convenience of changing frequencies and ID codes in the field. For me I would prefer not to have to deal with un-soldering the RUN pads, soldering the PGM pads then having to do that in reverse after the programming. Instead I would prefer to solder something like some mini dip switches or something that I could flip do my programming then change them back. Do you have a recommendation on this or any thoughts?

This would be useful to me in two scenarios:

- check the tracker board and my frequency is already in use
- want to launch more than one rocket and recover later

mpitfield said:

Hey Cris,

I would like to have the convenience of changing frequencies and ID codes in the field. For me I would prefer not to have to deal with un-soldering the RUN pads, soldering the PGM pads then having to do that in reverse after the programming. Instead I would prefer to solder something like some mini dip switches or something that I could flip do my programming then change them back. Do you have a recommendation on this or any thoughts?

This would be useful to me in two scenarios:

- check the tracker board and my frequency is already in use
- want to launch more than one rocket and recover later

Click to expand...

This is a great idea.

That is a good idea. I thought it would be good to have 4 pins that could have a jumper moved over for programming. Kinda like the ADEPT22 Altimeter.

BDB said:

This is a great idea.

Click to expand...

Eric said:

That is a good idea. I thought it would be good to have 4 pins that could have a jumper moved over for programming. Kinda like the ADEPT22 Altimeter.

Click to expand...

I have been looking for a SPST SMT solution but so far no go. All of the dip switches on Mouser and DigiKey are too long for the pads on the board. It would be easy just to solder any switch onto the pads but then the switch would be hanging off the board an prone to failure. I wonder if there is a way, in a future version, to move and situate both the "RUN" and "PGM" pads so they are closer to each other and allow for SMT dip switch to be used. In this case I am not sure if a DPDT or SPDT is required as I have not followed the traces, but this would be something Cris would know.

I have soldered on a right-angled 5 pin header strip to the PGM/RUN pads with the center header pin removed. It fits nicely over the pads. I can then use a shorting link on the appropriator remaining pin pairs. However, it might be better to angle the vertical pins towards the rear of the board away from the patch antenna to reduce any possible interference, but do this before soldering to the pads! You could use two 2 pin headers, but I think the 5 pin header arrangement is more secure.

mpitfield said:

I have been looking for a SPST SMT solution but so far no go. All of the dip switches on Mouser and DigiKey are too long for the pads on the board. It would be easy just to solder any switch onto the pads but then the switch would be hanging off the board an prone to failure. I wonder if there is a way, in a future version, to move and situate both the "RUN" and "PGM" pads so they are closer to each other and allow for SMT dip switch to be used. In this case I am not sure if a DPDT or SPDT is required as I have not followed the traces, but this would be something Cris would know.

Click to expand...

DPDT, there are no common traces. There's not much room there, I'm trying to come up with something to make programming the Mini easier in the future.