Eggfinder LCD - Handheld Display Receiver for Eggfinder GPS Tracker

[smapdiage9]

Here are some examples of what I see:

 

[tim cubbedge]

Can you post some photos of the soldering joints?

 

[smapdiage9]

Thanks for the suggestions so far. I hit all the solder joints again with no change, but at least they're blobbier now. My display pin/socket is reversed but I don't think that should matter.

 

[cerving]

You got one of the bad LCD modules that I had a few shipments ago, it's a 16x1 instead of a 16x2. Send an email to [email protected] and I'll replace it for you.

 

[smapdiage9]

You got one of the bad LCD modules that I had a few shipments ago, it's a 16x1 instead of a 16x2. Send an email to [email protected] and I'll replace it for you.

Well that's a relief, easy fix. Thanks!

 

[smapdiage9]

I mounted a 16x2 LCD from another project onto the LCD receiver while I wait for my replacement part and everything displays correctly. Great! Unnnnfortunately it doesn't seem like it's talking to my Tx and I'm not sure where I'm going wrong:

Eggfinder LCD powered up first. Goes through the screens per the instructions, and once I get to waiting for fix I power up the Tx.
Tx powers up fine, appears to get lock, and flashes the amber LED once a second or so. I also get flashing on the RF module red LED.

The LCD never moves off of 'Waiting for fix'. If I press and hold the button per the instructions, I do not ever get the expected red/green flashes on the receiver end. On button release it shows coords of 0.0000. Jumper is on RUN. I tried moving it to PGM, hooking up the cable, and entering program mode which works as it should, and gives me flashes on the red/green Rx RF LEDs so I assume the module is working.

Do I have to reprogram the Tx freq before use or am I doing something else wrong?

 

[cerving]

Not quite sure what you mean...

If you cable up the TX and LCD and go through the programming menus, both the RX and the TX's LEDs should be red/green at the end. Turn everything off, power them up without the cable (don't forget to put the jumper on RUN) and the green LED on the LCD's RF module should blink in sync with the red LED on the TX's RF module. If not, then there's probably some issue with the output format on the TX... check the pads on the GPS, and the two 2.2K resistors.

 

[smapdiage9]

At the end of program mode with the cable connection I have red and green on the Rx side but only red on the Tx side.

 

[smapdiage9]

Well I've been re-programming and re-flowing solder joints for the past couple of days with no luck. Here's what I've got at the end of programming mode:

The Tx unit appears to get a gps lock because my 1s LED will flash about 1hz. The red Tx RF LED appears to stay solid on pretty much all the time, including at the end of program mode where I still don't receive a green LED on that side.

 

[cerving]

You got a bad RF module on the TX side, email [email protected] and I'll send out a replacement. I got a couple of them in the last batch from my vendor, I've already spoken to him about it.

 

[smapdiage9]

Lol, I'm gonna work through your entire stock of parts. Just received the new screen, thank you for accommodating my reverse connection.

 

[smapdiage9]

Just wanted to say thanks to cerving, after the new LCD module and new Tx RF module my eggfinder seems to be working perfectly. Appreciate the support.

 

[ksaves2]

Just wanted to say thanks to cerving, after the new LCD module and new Tx RF module my eggfinder seems to be working perfectly. Appreciate the support.

Great to hear. You went through quite a tribulation and I applaud your soldering skills. I've dorked other projects by not quite desoldering correctly and torn pads off PC boards. That's a big time bummer sometimes hard to fix.

Worst mistake $$$$ I ever made was having a spring clamp snap when I was epoxying the capacitor to a brand new Raven 3 to the board. The clamp smacked the board and even though there is no apparent damage, if there is the least amount of torsion applied to the board, the Altimeter recycles or goes into standby mode. Stupidhead here did not do a bench test before doing the epoxy trick. It would have been dishonest to claim it was defective when I got it so I ate that one. Next one I used tape to hold the capacitor down while the epoxy cured and did the bench test before I did it. Kurt Savegnago

 

[smapdiage9]

Thanks! I'm on to my next customer service question because I started assembling my Eggtimer TRS today: I hit the point in the instructions where I test out the GPS and RF modules and it's behaving a bit weird. Transmit and Receive are working great, and I appear to get valid GPS coordinates, satellite number, bar graph, and seconds since last update, but the altitude display is wonky gibberish.

I've reattacked every solder joint and tested for shorts and it all seems fine. Is there something peculiar about the altitude data that could point to an area on the board I should check out?

 

[KenECoyote]

I had good use of my Eggfinder LCD today...rocket was DD with black body, red nose cone and two yellow chutes and had a great flight on a I165 C-Star motor, good event and nice landing not too far out in the seeded sod field, so it seemed like an easy recovery. I still left the Eggfinder on and tracked it as I was walking and was surprised I couldn't see it in the field as I was walking towards the site...I started to think it was way off. Suddenly it started noting it was to my side...then I saw it. It had landed right alongside a ditch (couldn't see it from where we were initially...even the announcer didn't see it). The black body of the rocket was resting in the "black dirt" (actually that's what this region is known for) and the yellow chutes and red nose were in the ditch, so it hid itself very well!

 

[cerving]

Thanks! I'm on to my next customer service question because I started assembling my Eggtimer TRS today: I hit the point in the instructions where I test out the GPS and RF modules and it's behaving a bit weird. Transmit and Receive are working great, and I appear to get valid GPS coordinates, satellite number, bar graph, and seconds since last update, but the altitude display is wonky gibberish.

I've reattacked every solder joint and tested for shorts and it all seems fine. Is there something peculiar about the altitude data that could point to an area on the board I should check out?

Check the 74HC02's solder joints on the TRS with a magnifier, it multiplexes the GPS output with the CPU's altitude data feed. You can also connect the data cable to your receiver (BLACK-GND, WHITE-RXD) and fire up your terminal program (9600/8/N/1), you should see the altitude data interspersed with the NMEA GPS data.

 

[smapdiage9]

Check the 74HC02's solder joints on the TRS with a magnifier, it multiplexes the GPS output with the CPU's altitude data feed. You can also connect the data cable to your receiver (BLACK-GND, WHITE-RXD) and fire up your terminal program (9600/8/N/1), you should see the altitude data interspersed with the NMEA GPS data.

Thanks, I'll magnify it when I get home. In the mean time here's a pic I took yesterday:



Nothing is wrong with that component to my eye, and when I plugged the TRS in this morning everything functioned perfectly with the altitude reporting. So I guess either something is intermittently connected (I'll re-flow them again) or I had a stray bit of gunk causing a bridge somewhere that has since moved?

Also in that pic you can see where a solder pad fell off for one of the 2.2k resistor attachment points and I had to improvise with a bit of cut off LED lead wire. It ripped out the instant my iron touched it, not by any undue force, but since the device is apparently working I guess that fix will do.

 

[smapdiage9]

I've inspected it and resoldered every joint on that component. The TRS transmits good data and everything seems to operate perfectly...unless I shake the board around or tap the 74HC02 in which case beeping stops, altitude goes weird again. So gentle lift offs only I guess?

 

[ksaves2]

I've inspected it and resoldered every joint on that component. The TRS transmits good data and everything seems to operate perfectly...unless I shake the board around or tap the 74HC02 in which case beeping stops, altitude goes weird again. So gentle lift offs only I guess?

Sumpt'in wrong. I had a spring clamp slip and whack a new Raven III I was securing the capacitor to the board with epoxy. No apparent damage but the altimeter would recycle with the slightest of board torsion. I wouldn't fly it if I were you.

My TRS units are pretty tough. I fired 'em up with a pyro battery applied and LED's on the outputs. I shook 'em and gently tapped on the larger SMT components and experienced a rock steady ready for flight warbling. No unexpected
issues during this low mode stress test. I then took a ham radio handie talkie and blasted 5 watts of FM Rf in 2meter, 1.25meter and 70cm bands of a variety of frequencies in a variety of positions nearby. I put contained ematches on
the outputs for that test. Nothing deleterious happened. Nada. The only thing I was able to do was I succeeded in changing the pitch of the warbling sound when I touched the tip of the handie talkie antenna to the opto-isolator chips while
transmitting the Rf. When I stopped transmitting, the tone went back to its nominal sound. The TRS remained in flight readiness mode with no shutdown, resets or popping of the ematches. I had two different lead lengths for the ematches. I think the units are pretty tough based on this simple (though unscientific test)

I'd see if Cris could send you a new component and replace it. Clip the leads of the old one and desolder the remaining lead ends off the board and place a new one. Would have to remove the piezo to accomplish
and resolder it back in. Best of luck. Kurt Savegnago

 

[djs]

I've inspected it and resoldered every joint on that component. The TRS transmits good data and everything seems to operate perfectly...unless I shake the board around or tap the 74HC02 in which case beeping stops, altitude goes weird again. So gentle lift offs only I guess?

sounds like a bad solder joint in that area. Can you follow the traces from the 74HC02 and see what it's connecting to, and then reflow the joints on those components?

 

[cerving]

You know, I just caught that you don't have the processor installed... that's why you're getting gibberish for the altitude. Don't worry about it if you're getting the latitude/longitude on the display, that's what this test is for. Go ahead and install the processor, buzzer, etc., and it should be fine.

 

[ksaves2]

You know, I just caught that you don't have the processor installed... that's why you're getting gibberish for the altitude. Don't worry about it if you're getting the latitude/longitude on the display, that's what this test is for. Go ahead and install the processor, buzzer, etc., and it should be fine.

Woooo heee, I just assumed that was an interim photo he was showing and the processor was currently on the board! Shoot, get that puppy soldered on there and it should work then. Kurt Savegnago

 

[smapdiage9]

It's aliiiive!! Thanks.

Now make one that has accelerometers, staging, and four pyro channels so I can give you more money.

 

[SpaceManMat]

Thought I post my EggFinder setup. I've modified a Caliber ISP so that I can put DD in it, but at this stage I'm only using the coupler to carry a test payload. The EggFinder 4b) has been modified a little. I've removed the standby switch and connected a plug so that the unit can be operated by a single pull pin (more about that setup later). I've also added a super cap which is soldered to the 3.3v output. The super cap keeps the EggFinder running for about 2 seconds in the event of a power failure.

On the other side I have the battery, switches and an EggTimer that is also being tested. As this is only a tested bed I've just connected everything using the EggTimer terminals. Now I should explain the switches, the switch at the bottom of the picture is the standby switch, with the pin removed this is off rather than on. The top switch is the main power switch for both the EggFinder and EggTimer.

The power on sequence is as follows.
1. Turn on the LCD RX and wait for it to power up.
2. Pull the pin out half way, this in turn powers up the EggTimer and puts the EggFinder TX into standby.
3. With the pin still in halfway, wait for 3 seconds. While the pin is half in the Standby button is on, it takes a 3 second closed circuit to bring the EggFinder out of standby. This happens when the EggTimer does its first beep for the 30 second countdown to flight mode.
4. Withdraw the pin completely. If you've done it right the LCD should report the lock by the time the EggTimer is ready to fly.

Shutdown is pretty much the reverse. Put the pin in half way wait 3 seconds, the the LCD should report loss of lock. Push this pin in fully to shut down both units, but don't wait too long as the EggFinder will eventually power back up.

Here's how I built the LCD unit. Power button is on the left, the right toggle switches are for the BlueTooth transmitter and the Backlight. The push button is the set / recall button.


Note that I did not put the standard PCB mounted switch that comes with the kit, instead I soldered a plug to the board. The BlueTooth toggle switch is wired to the positive and negative power feed to the Bluetooth unit, but if you are building the LCD to use with a the new TX then you will want to set this up differently.


I wanted to record a full mnea tacking log of the flight, so I used the BlueTooth connection on my laptop. I used a program called GPS Gate that is able to pipe the incoming mnea data stream to multiple outputs.

The first output I used was to send the data to Google Earth. GPS Gate has a inbuilt interface for this purpose and I found this worked better than using the GPS interface within Google Earth. Data comes up in realtime and is saved into a KMZ, you can take a copy of this anytime after the flight. Only issue with Google earth is to remember to cache your maps before hand.

The second output I used was sent to Visual GPS, which shows you all sorts of details about number of satellites, their positions and signal strength etc. All of which are cool, but the critical reason I used this was to log the full mnea data stream. Unfortunately this is turned on manually and despite multiple tests I managed to stuff it up on the day.

Here's how the 2 programs look, as I don't have a log there are no details shown on Visual GPS. BTW I created a batch file to run all the programs in one hit, including the inbuilt BlueTooth connection utility.

So I'm looking at alternates for this, GPS gate does have file logging but it is a paid option and I prefer free, does anyone know of a good alternative logger?

The other thing I wanted to do was to merge the tracking data with the altimeter data to accurately recreate flight. I've tried a few tools but nothing seemed really useful in this regard. Has anyone tried this before?

 

[ksaves2]

Xastir is free but a real PITA to setup as it's a Linux Ham Radio APRS ap. Maps are getting really tough to install now as the OSM source tailored for the program has dried up last I looked. Have to use a script: https://www.ece.uah.edu/~jdw/rockets/gps2aprs.txt to pipe the NMEA into APRS code so it is tracked.
Nice thing is one can log it, repaint it on the screen later and also it will automatically save the data as a .kml file.

Your current solution might just be the best that can be had but if someone else pipes up, I'd be interested in a windows solution. Even a paid program would be fine as long as it has everything you want and will use it all the time. Kurt Savegnago

 

[SpaceManMat]

Xastir is free but a real PITA to setup as it's a Linux Ham Radio APRS ap. Maps are getting really tough to install now as the OSM source tailored for the program has dried up last I looked. Have to use a script: https://www.ece.uah.edu/~jdw/rockets/gps2aprs.txt to pipe the NMEA into APRS code so it is tracked.
Nice thing is one can log it, repaint it on the screen later and also it will automatically save the data as a .kml file.

Your current solution might just be the best that can be had but if someone else pipes up, I'd be interested in a windows solution. Even a paid program would be fine as long as it has everything you want and will use it all the time. Kurt Savegnago

If your willing to pay then the paid version of the paid GPS gate client option would probably be ideal (I think it is $40). This week I tracked down RS232 Data Logger by Eltima Software. There's really no need for a NMEA specific solution, just a virtual com port logger. It's a bit clunky but is does give you a live figure for bytes read/write readout which is enough to confirm you are writing a file. One other thing this is open source so there is potential to customise it for your needs.

if anyone is interested I can supply details about how each program is configured

 

[SpaceManMat]

I've been playing around with flight data from my trial flight of my EggTimer and EggFinder. One of the issues with the EggFinder is that the altitude given is very poor. So my aim is to combine altitude data from the EggTimer and produce an altitude corrected KML to display in Google Earth. This is the result of my first attempt, the black line is the original data that was recorded, the red is the corrected.

To do this I created an excel spread sheet and used VB code to import the EggTimer log which is pretty simple as it is a CSV. For the EggFinder I only had KML data, although they use XML and Excel can is in theory XML capable, all the Long, Lat and Altitude entries are all strung together inside a single field. So the code to extract this is more complex and just to make things more interesting I found that the co-ordinates had in fact been recorded into the KML in reverse order. The export feature recreates the KML with the adjusted data in the spreadsheet. This is the main worksheet

The launch site altitude is required so that the AMSL altitude can be calculated. The timing adjustment is used to synchronise the KML and EggTimer timelines. If the GPS data starts after the EggTimer then the initial GPS co-ordinates are extended back in time by assuming that the rocket has not moved from that Long and Lat. Also there is an option to enter the final landing co-ordinates if these have been manually recorded.
I've attached all the files in a zip file so you can have a play around. Note that if you do reimport the EggFinder data, there is a corruption in one of the Longitude co-ordinates, I manually correct for this by averaging the value before and after.
View attachment EggConversion.zip
Feed back on this approach would be very much appreciated as I want to further refine this technique. My thoughts are that although the adjusted KML is certainly much more representative of the flight it still lacks accuracy. There are a number of reasons for this I suspect:
1. The KML is shorter than it should be given that it was recording before liftoff and only ends right before the landing (rocket was found about 4.5m from the last co-ordinates.
2. No timing data is recorded in the KML but as the co-ordinates are taken every second it is assumed that each subsequent coordinate is 1 second apart.
3. I believe that almost all data made it back during the flight but I do know that at least 1 co-ordinate did not.
4. Given the above I believe that Google Earth only records the first of any duplicate co-ordinates that it receives, which makes a fair amount of sense if you think about it. Although this sounds bad from my perspective, but the reality is that this should really only occur while the rocket is on the pad.

 

[ksaves2]

Interesting solution. One can use a different GPS receiver with the EggFinder. I found that out when I broke the Maestro Sirf 4 off the board. Only issue is the timing is off so the altitude isn't displayed correctly with GPS rocket locator but the
information in the datastream is in there and accurate. Kurt Savegnago

 

[bill2654]

I need HELP!! I have a LCD receiver and I got a new case from BLKKRW and after transferring it to it's new case, it quit working.
Well I contacted Cris and he told me I need to reflash it. Well I know this is a DIY kit but when it comes to computers, Im a total caveman.
I need someone who has done this before and is familiar with programing EF's. I will also need the EF installed into the new case when finished
reflashing. I also have 1 TX that I need to have the freg reset. I tried but no luck. I will be glad to pay for your services but if you prefer to
keep these arrangement private, PM me and we can work something out. Cris is just too busy to get to this and I have had an offer
from someone here (Thanks Steve) to walk me through the procedure but I just cant go that route. Thanks in advance.

 

[dixontj93060]

Kind of scary that code can go haywire just through physically remounting(??).