Testing with a module you have there will be fine, if it works we’ll know it’s either an issue with my GPS or my Raptor. I was just surprised not to hear any suggestions for you guys for debugging this.
I’m currently trying to get it working on the Cobra II. Unfortunately, every time I try to program the Cobra II it crashes my Win 7 PC so I’m installing everything on my Win 8 PC w/ VS 2012, see if that works.
I’d rather the Raptor since it’s almost 2x as fast, but if I can just get this working on really anything with more power than the Cerb, I’d be pretty happy.
I haven’t got one. Nor have I a scope. I’m a software guy, not a hardware guy. Which, really, is what Gadgeteer is supposed to be. Gadgeteer is billed as “hardware for software people”.
I know your at your ends whit with this. But maybe you might be able to try RobvanSchelven idea. I know you said you don’t have one, but you just might and not know it.
Maybe you have an old laptop PS laying around that you can cut the cord off.
All of the laptop PS i have seen have a ferrite on the cable. Its that big round looking thing on the cord. Cut through the material to remove the cable from the ferrite, and then feed your wires from one board to the other through it. Even better if you can make a loop or two through it before coming back out. Also take a gander at some other cable you may have like an old VGA cable those have them as well.
Hi Tom,
For the ferrite, grab any video camera you have laying around and check it’s power supply, you should find a removable ferrite around it’s power cable…
And now for those of you who care how to get GPS running well on Gadgeteer.
If you’ve been watching up to this point, you know I’ve had a hell of a time getting GPS to work adequately on really any Gadgeteer board. The best result I could get was on a Cerberus and even that took upwards of 2 mintues. On the Cobra II it took 15min on USB or wall power and 11min on LiPo. Raptor and Hydra were right out.
So why is Adafruit’s version the only way to go? Because it has a battery backup. A simple 3V CR1220 coin cell keeps the receiver in a standby mode that allows warm starts over cold. It also has an Enable pin that allows me to put it into low power mode.
OK so what sort of difference are we talking here? Well, my record on the Cobra II last night was a bit over 11 minutes. My record today (on warm start) was about 5 seconds.
5 seconds.
Obviously it has the draw back of not having a Gadgeteer socket, but that’s what the Expander modules are for. And, of course, boards like the Cobra II or HDR boards have PTH headers that remove the need for a socket.
Frankly, I was ready to walk away from NETMF altogether and not look back for months or years. Because simple things should be simple.
@ GHI - I know the GPS module is Seeeds, but now that you have your nice shiney manufacturing setup I think you would do well to take Adafruit’s design and slap a socket on it. Heck, I wouldn’t be surprised if I could use Hydra & Raptor to get a lock now that I have a battery backup (yes, I do plan on testing that).
Thanks everyone that listened to my absolute bitch fest and tried to help me get something running. I’ve been trying on and off for over a year to get a specific project done for my fiance and kids and now I finally can get it going.
I just got locks on both the Raptor and the GPS dreaded Hydra. Both in 5 seconds or less (warm start). I expect the first ever cold start would take forever but once done you’re golden. You could even just power the GPS outside of the board the first time to enable warm start.
It sure does. This allows the GPS receiver to retain the almanac and this page explains that time you are seeing. Having the battery backup allows the almanac to be used when the GPS powers up instead of having to download it all again.
I think my comments were highly relevant to the troubleshooting. I was in contact with another user who was troubleshooting THIS EXACT SAME ISSUE, and what made the difference was 1) what power board was used, and 2) how much power filtering was done on the GPS module itself (ferrite bead was a must, as was aggressive decoupling). I’m sorry that the truth isn’t flattering, but that doesn’t make it not the truth, and it doesn’t make it not relevant. Suppressing the truth does your company and your customers a disservice. You can’t fix what you can’t admit.
@ Skewworks: Even if your warm start is much better, there’s still no excuse for 15- or 11-minute cold start times.
I’m absolutely not “on a quest”, unless by that you mean that I would like to provide insight into one possible cause, based on knowledge I have of a user troubleshooting the exact same symptoms.
GPS is extremely sensitive to “dirty” power, i.e. lousy line or load regulation, high frequency noise on the power rail, poor decoupling, etc. These things can lead to exactly the symptoms seen here, i.e. slow or non-existent fixes, or inability to maintain a fix.
The designers of the GPS module probably assumed that the power supplied to the module would be “clean”, i.e. free of the previously-mentioned artifacts. In at least some cases (for example, the previously mentioned case), that was not true, when using GHI’s power modules. I don’t think “free from high frequency noise” can really be considered “non-standard power requirement”. Certainly GPS is much more sensitive than, say, an LED, but a designer of a power supply should strive to minimize these artifacts that have negative impacts on the rest of the system.
As for the battery on the module, it has nothing to do with overcoming the dirty power, it simply allows the GPS module to hold onto the almanac data in order to skip the most lengthy part of the startup process.
By the way, Adafruit’s “Ultimate GPS” module’s datasheet says that cold time to first fix should be “35 seconds typical”.
@ godefroi - Ok. How would you fix the current Power modules from GHI, or Solder Monkey (I think Skewworks tried that one as well) so it will provide “clean” power?
I’m not an EE, nor am I experienced in power supply design, so unfortunately I have little to offer on the design-side.
There was, several weeks ago, a detailed hardware analysis of one of the power modules, with a list of things that weren’t right, as well as scope traces that demonstrated the problems. I might be able to dig that up.
@ godefroi - I absolutely appreciated your insights
Personally, I can’t help feeling like quality has gone down recently on GHI hardware & software alike.
Remember the first versions of Cobra, Panda, the Domino? They worked with anything I put on them, without fail. Hell, I put an FM Tuner inside of a case sitting between the Cobra & it’s 4.5" LCD and I got signal with nothing more than a 1" piece of stripped wire.
These days we have touch screen issues that somehow take 6 months to fix (while in the mean time there’s a simple Register fix…how about putting in that fix and shipping it with the firmware sometime faster than half a year).
Or the reoccurring can’t use a serial port at the same time as a touch screen issue? That shouldn’t have made it passed QA once, let alone twice.
This isn’t coming from a newbie that arrived and is pissed things didn’t work straight off. I’ve been buying GHI stuff for years and spent several grand on it.
I recognize we all clamor for this new gear and GHI is doing its best to respond but maybe, just maybe, quality is starting to get sacrificed in the name of quantity. I long for those good old days of Cobra I where I could enact any idea I had as quick as I could get the components in.
The ideas are great. I love my Hydra’s, Cobra II and Raptor. I’d love them even more with stable firmware and the ability to add simple modules without massive headache.
Have to agree a little on this with Thomas. The fact that a G400 with a 400Mhz processor cannot handle serial over 19200 is just downright crazy. I have used Atmel AVR devices with 2 serial ports running at 115200 and no loss of any bytes. The fact that the issue is present in the old ChipworkX module and still present in the G400 needs someone to take a seat, lean back and think how this occurred and how can it be fixed.
It’s a major deal breaker for me just now. The G400 works for all other parts of my design but my client is jumping up and down as to why the over the air update it not working on the existing ChipworkX modules. The fact that the serial port overruns on a connection means I cannot do the download. I don’t want to move away from GHI and NETMF as the support has been first class but some things are taking a little too long for me to be able to work with it.
I am sitting here at my desk with 2 alternatives. An Android embedded system (which works 100% for the last 12 months at a clients site and can do auto updates etc) which I have added to support GPIO, SPI and I2C so all my hardware IO works with it. The second is another embedded device but that has no LCD interface so needs a special board.
If GHI can get the serial port sorted as fast as humanly possible, I will remain with the G400. That and the awesome Newhaven capacitive LCD makes a bloody good embedded system. Oh, and please add PPP as a priority to the list.
@ Dave McLaughlin - we already confirmed and explained the problem with an update coming soon to cover this. G400 has a lot to offer with tons of features, which is why you picked it I think, but I agree this needs to be updated ASAP like we talked about already. I hope this issue would not put a judgment on the whole product. We are always looking to improve.
