|
»
»
»
EVK-5H
|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
 |
EVK-5H
by gpsd
::
Rate this Message:
Hi All,
I have a Ublox-5 EVK-5H sitting on my desk, one of the wish list items. I'm a rather experienced embedded programmer: how can I help? (just compiled and installed gpsd-2.37 on my Athlon 64-bit dual core machine, a little annoyed that the EVK-5H is just a generic NMEA device, and unable to set this critter to accept EGNOS test mode messages) Henk _______________________________________________ Gpsd-dev mailing list Gpsd-dev@... https://lists.berlios.de/mailman/listinfo/gpsd-dev |
|
|
Re: EVK-5H
by Chris Kuethe
::
Rate this Message:
On Sun, Jul 20, 2008 at 2:39 PM, <gpsd@...> wrote:
> Hi All, > > I have a Ublox-5 EVK-5H sitting on my desk, one of the wish list items. > > I'm a rather experienced embedded programmer: how can I help? have a look at our bug tracker and fix a bug? http://developer.berlios.de/bugs/?group_id=2116 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488913 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488915 here's one i just noticed: error estimates are not (often|ever)? updated in anti-jitter mode. this means that if you do "cgps -j gpsd.mainframe.cx" you'll often get a reasonable error estimate, but sometimes you'll get garbage. error estimates that are obviously erroneous, but they never update. i've been meaning to implement mode-switching for ubx devices, just haven't done that. we have most of the machinery in place: a method to probe and identify receivers, ublox protocol decoding, and other drivers (like SiRF) which do this already. this might be an excellent way to familiarize yourself with the codebase. or if you have other ideas, we'd love to hear them. > (just compiled and installed gpsd-2.37 on my Athlon 64-bit dual core machine, > a little annoyed that the EVK-5H is just a generic NMEA device, and unable to set > this critter to accept EGNOS test mode messages) Urrr? You mean u-center won't force the receiver to accept test mode? CK -- GDB has a 'break' feature; why doesn't it have 'fix' too? _______________________________________________ Gpsd-dev mailing list Gpsd-dev@... https://lists.berlios.de/mailman/listinfo/gpsd-dev |
|
|
|
|
|
Re: EVK-5H
by Chris Kuethe
::
Rate this Message:
On Mon, Jul 21, 2008 at 6:15 AM, <gpsd@...> wrote:
> What say? Use a non-Linux app to set-up for Linux? You mean "Use a windows app to set up for non-windows?". > There must be a better way to do that! Why not? This is why I have a small qemu image - to run vendor gps tools. The vendor tools good way to kick the receiver into a state you want, and you can often monitor the actual control messages (which may differ from the manual). You don't have to do that very often - just until you have a skeleton of a program that can do it, and you've verified the manual is mostly correct. CK -- GDB has a 'break' feature; why doesn't it have 'fix' too? _______________________________________________ Gpsd-dev mailing list Gpsd-dev@... https://lists.berlios.de/mailman/listinfo/gpsd-dev |
|
|
Re: EVK-5H
by Greg Troxel
::
Rate this Message:
What say? Use a non-Linux app to set-up for Linux?
I know what you mean, and Chris's comment was perhaps not obvious to everyone, but your words, probably uninentionally, conflated "proprietary software that runs only on Windows" and "non-Linux", leaving out that there are a lot of other Free and some non-Free operating systems that run gpsd. Your real issue, to which I am entirely sympahtetic, is that there is some blob from the vendor that you can't modify, share or improve, and that you can only run on Windows - dreadful indeed. Those of us that run systems other than Linux (Chris OpenBSD, and I who more or less looks after the gpsd entry in pkgsrc for NetBSD) are a bit sensitive on this point, as we know what it's like to be a minority. There must be a better way to do that! Indeed, but the path often seems to be to hold your nose and use the Windows-only program and capture input/output and then write some free code to deal. _______________________________________________ Gpsd-dev mailing list Gpsd-dev@... https://lists.berlios.de/mailman/listinfo/gpsd-dev |
|
|
Re: EVK-5H
by Chris Kuethe
::
Rate this Message:
On Tue, Jul 22, 2008 at 5:41 PM, Greg Troxel <gdt@...> wrote:
>> There must be a better way to do that! > > Indeed, but the path often seems to be to hold your nose and use the > Windows-only program and capture input/output and then write some free > code to deal. Blatant hand-wave and laziness in not providing a citation: I seem to recall a certain outspoken figure in the F/OSS world (famous for railing against proprietary software) grudgingly admitting that it's ok to use closed, proprietary tools to develop open and free replacements of those tools. Heck, there's a grand tradition of doing just that. That's how I got started with gpsd - I wrote a perl toolkit to do on *NIX what SiRFdemo does on Windows. Spent quite a bit of time validating it against the Windows tools. And then this guy calling himself Eric mails me asking all these questions about SiRF receivers... it was all downhill from there. Eventually, we (gpsd) came up with a set of tools that sometimes works better than the Windows tools. Occasionally you just have to suck it up and use some horrible software for a little while to help get you started on building something better. It's a noble calling... because we're not paying you enough to do it for the money. :) CK -- GDB has a 'break' feature; why doesn't it have 'fix' too? _______________________________________________ Gpsd-dev mailing list Gpsd-dev@... https://lists.berlios.de/mailman/listinfo/gpsd-dev |
|
|
Re: EVK-5H
by Eric S. Raymond-2
::
Rate this Message:
Chris Kuethe <chris.kuethe@...>:
> On Tue, Jul 22, 2008 at 5:41 PM, Greg Troxel <gdt@...> wrote: > > Indeed, but the path often seems to be to hold your nose and use the > > Windows-only program and capture input/output and then write some free > > code to deal. > > Blatant hand-wave and laziness in not providing a citation: I seem to > recall a certain outspoken figure in the F/OSS world (famous for > railing against proprietary software) grudgingly admitting that it's > ok to use closed, proprietary tools to develop open and free > replacements of those tools. Heck, there's a grand tradition of doing > just that. Yes, RMS used to say that. He clammed up on the subject after we bootstrapped our way to viable open-source operating systems, but you could probably still get him to admit it if you backed him into a corner and pushed. My attitude has always been "Use the tool that works" -- as long as you recognize that your evaluation of "works" has to include the forward risks of relying on proprietary tools. > That's how I got started with gpsd - I wrote a perl toolkit to do on > *NIX what SiRFdemo does on Windows. Spent quite a bit of time > validating it against the Windows tools. And then this guy calling > himself Eric mails me asking all these questions about SiRF > receivers... it was all downhill from there. Actually, all I had to do was get a look at Chris's website to realize that (a) we needed him on this project, and (b) he would want to be on this project if he knew about it :-). -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> _______________________________________________ Gpsd-dev mailing list Gpsd-dev@... https://lists.berlios.de/mailman/listinfo/gpsd-dev |
|
|
|
| Free Forum Powered by Nabble | Forum Help |