Posted by Scott Plunkett on September 11, 2009 at 8:31pm
I have been looking around for some time for a good GPS solution that fit all of my needs, had great compatibility with other components (without a ton of work on my part) AND gave me the features / performance I have been looking for…guess what – I found very few, and when I found them they were usually out of stock! So, I decided to look into putting together my own. I have the board designed, parts sourced, and a design/ fab house on board to help me make it happen. I am waiting on a final BOM (Bill of Materials), Logic Test, and DFM review before I will know what the actual parts / production cost is – but it got me wondering, so…I am looking for feedback – trying to determine whether or not anyone would want the following, and what you’d be willing to pay for it?GPS Module Specs:Ultra High Sensitivity–148dBm (Cold Start Acquisition)–165 dBm (Navigation)Low power consumption: 75mW @ 3.3V10Hz Fix RateNMEA protocol (default speed: 9600bps)WAAS/EGNOS support22 Tracking Channel – 66 Acquisition Channels (Best in Class)Cold Start (out of the box): 34s typ.Warm Start: 33s typ.Hot Start: 1s typ.Protocol: NMEA 0183, @ 9600 baudSensitivity:Acqusition (cold):-148dBm - Re-Acquisition:-160dBm - Navigating/Tracking:-165dBmPower Drain: (3.3V): Navigating: 1 fix/s: 75mW typ. - Backup state: 15uW typ.Active Sarantel GeoHelix Quadrifilar antenna:Right-hand circular polarized, 3.3 V, 50 Ohm, SMT mounted directly to the PCB board, +25 dBic Gain and operating temp between -40 and +85 degrees C, weighing 8.4 gramsOnboard Data Logger Specs:The data logging component incorporates the LPC2148 ARM 7 Processor with USB, battery charging, and microSD support. This allows use of the OpenSource SparkFun LPC2148 USB bootloader for fast and easy modification of the datalogger firmware without using a programmer. The logger employs a USB mass storage stack to appear under any operating system as a flash drive. Logs are created in FAT16 format on the micro-SD media and can be downloaded quickly over a USB connection by dragging and dropping the text files from the device. The microSD card can also be removed and inserted into a card reader to download the logs. Board comes with a JST connector to be powered from a LiPo battery or other power sources. If you choose to use separate LiPo batteries for GPS functions, the unit has a built-in charger to charge batteries off USB. Additional pins available for logging of additional information (temp etc. with add-on boards and firmware modification,,it is OpenSource baby!)Ships with 2GD microSD card and SD Card AdapterAdditional Board-Level Specs:Board has outputs from both of the GPS antenna UARTs, and data can be found on TTL (Raw GPS data for telemetry, I2S, and a connector compatible with the output from the EM406a GPS (ArduPilot Compatible – no adapter board required) An additional output is provided for sending data to a compatible OSD system (RVOSD compatible – plug and play.) A small rechargeable battery keeps the GPS config and datum on board for quick fixes.Please keep in mind, a comparable data logger is $60 dollars (although we could go cheaper if we dumped the microSD card slot and USB connectivity, but I love the elegance of this solution) and a comparable, but lower performing UBlox GPS unit is between $90 and $100 depending on where you buy it, if you can find it.So now with all that said…what is it worth?
They even have a serial port - but I believe the problem you are going to run into (if any) is that most chip sets today (that have the higher performance) are doing post processing onboard - BUT some of the units support a binary output that will in some cases give you the attitude you are looking for without having to crunch the numbers yourself.
I am interested in a GPS system with decent accuracy and Carrier Phase output (for GPS attitude measurement). Right now Sirfstar II's are the only low-cost, small GPSs I have seen with CP output, but don't meet the decent accuracy requirement. Any GPS with RAW output would also meet the requirement. Price would depend on other specs.
SO what I think I am taking away from this discussion is several things.
One: The device, whatever it is needs to be user configurable, meaning you guys can pick and choose which protocol you want output - this is usually the case with these modules so nothing new there (just that many people in the DIY community prefer the binary data) Making that easy to do with a DIP switch would be cool...right?
Two: It is difficult to discern what the end user really wants when I too often factor in what I want.
Three: Regardless of the chosen path - to be clear I have already chosen, and will be making 15 of these, likely with more features than described here - and I will make them available at my cost to the community - who knows, maybe it will be something that people like for the price - BUT, regardless of the chosen path the config is the key...mold together the right parts in the right modules and then bring all that together with some free and open easily reconfigurable code...then the stars align...and you could have a product that sells. - SO, that said - it's all about the config.
Four: Even the most innocuous question - ie. "What would you pay for xxx?" posted on a forum such as this will generate an interesting discussion, even if the actual question never really gets answered...I am laughing as I type this, not peeved.
Five: In the end, you just have to keep building, and playing, and coding and breaking things, and discovering, and learning, and eventually you'll get to a point where you realize you can build it yourself - but that may not mean that you should or that others will actually want it too!
Thanks for all the input and the great discussion. I will let you all know how things progress as I get these built. If you'd be willing to help me pick apart the particular version of binary in this thing, I'd be willing to send you a freebie sample - just drop me an email or send me a message here.
There are two benefits to binary protocol:
one, com ports are in limited supply on these small boards, and two, the standard com protocols don't include all of the available information. I doubt the problem you are trying to solve is on the interface side - rather it is on the radiometric side of the gps chip. just expose the chip interface as it is, and leave out the mpu.
Kbosak, you make good points and I can understand your frustration. But I'm not sure why you're so negative about the ability to have open source coexist with commercial, which it obviously has done well in other domains (I did write a book about this after all!).
I think you've rightly identified the two successful paths in our world:
1) Very cheap open source DIY tech, which is typically componentized and requires some work and expertise on the part of the user to get going (ArduPilot, Paparazzi). In this case the commercial opportunity is in selling hardware, while giving away all the IP for free. You're right that the all-in price of these autopilots tends to be around $300-$350 including wireless telemetry and ground station, although that will fall.
2) More expensive RTF solutions, such as yours ($1,500 without wireless telemetry and ground station) and AttoPilot ($800 now, but probably a similar price as yours for the IMU version) for those who who can't or don't want to get into the mechanics of this stuff (or don't need the flexibility of open source). In this case, you can charge for IP.
So it's pretty simple: the marketplace can choose between cheap and somewhat hard to use, or pay 4-5x more for something that's easier and more reliable, at least in the short term. (Sort of like downloading MP3s for free from P2P sites or paying for them in iTunes.) I'm going to assume that the functionality differences between the two approaches will continue to shrink as the open source world collectively improves the products, just as it did with Linux and Windows. Certainly Paparazzi is technically as good as many commercial solutions.
Scott, the problems is that while I am the guy who would like your product for 500USD, you are 3 yrs late for me. The others might include logging of 5 parameters to ardupilot one month after you release yours and 'be happy with it'. The real problem is once we claim on diydrones the autopilot can be done for 99USD and then silently add addons around it that go up to 300USD, and the setup we fly easily go into 1500USD, the whole economy thinking enters swamp area where the real price for good engineer's work is NULL and teh numbers are juggled liberally. I agree the real value is in final integration, this is why I did my autopilot from scratch, and there are no 'unwanted artifacts'. In fact the social problem of diydrones is while theoretically a 'group of volunteers can do anything', this 'anything' is often scratching a surface in all areas blocking the chance for someone to develop highly developed, specialised solution that would blend into. I would say, open source and commercial doesn't really mix, not because of competition, but because of randomness and high risk introduced by open source to 'nearby' commercial developments. I would say, there must be clear, readible and significant difference between commercial and opensource (target group, complexity, reliability, simplicity) or else either commercial or opensource with eat the other. After years, most open source ends like this: top 5 developers say 'it's ours anyway', develop support group anything well paid, then nobody wants to pay for something that was 'free' for years, then the groups starts completely different commercial product and succeeds.
Sorry...got too verbose...In parts alone before the PCB we're at like 50-55 dollars. I don't need any significant margin on these things...I'd just like to cover all of the expenses (shipping, et al.) in the long run.
Comments
Sorry for the brokem link above - the downside to this thing is it is older tech, only 12 channels, etc.
It also has full raw output.
Manufacturer info here:
(Release)
http://www.thalesgroup.com/Press_Releases/Security_PressReleases_20...
They even have a serial port - but I believe the problem you are going to run into (if any) is that most chip sets today (that have the higher performance) are doing post processing onboard - BUT some of the units support a binary output that will in some cases give you the attitude you are looking for without having to crunch the numbers yourself.
One: The device, whatever it is needs to be user configurable, meaning you guys can pick and choose which protocol you want output - this is usually the case with these modules so nothing new there (just that many people in the DIY community prefer the binary data) Making that easy to do with a DIP switch would be cool...right?
Two: It is difficult to discern what the end user really wants when I too often factor in what I want.
Three: Regardless of the chosen path - to be clear I have already chosen, and will be making 15 of these, likely with more features than described here - and I will make them available at my cost to the community - who knows, maybe it will be something that people like for the price - BUT, regardless of the chosen path the config is the key...mold together the right parts in the right modules and then bring all that together with some free and open easily reconfigurable code...then the stars align...and you could have a product that sells. - SO, that said - it's all about the config.
Four: Even the most innocuous question - ie. "What would you pay for xxx?" posted on a forum such as this will generate an interesting discussion, even if the actual question never really gets answered...I am laughing as I type this, not peeved.
Five: In the end, you just have to keep building, and playing, and coding and breaking things, and discovering, and learning, and eventually you'll get to a point where you realize you can build it yourself - but that may not mean that you should or that others will actually want it too!
Thanks for all the input and the great discussion. I will let you all know how things progress as I get these built. If you'd be willing to help me pick apart the particular version of binary in this thing, I'd be willing to send you a freebie sample - just drop me an email or send me a message here.
one, com ports are in limited supply on these small boards, and two, the standard com protocols don't include all of the available information. I doubt the problem you are trying to solve is on the interface side - rather it is on the radiometric side of the gps chip. just expose the chip interface as it is, and leave out the mpu.
I think you've rightly identified the two successful paths in our world:
1) Very cheap open source DIY tech, which is typically componentized and requires some work and expertise on the part of the user to get going (ArduPilot, Paparazzi). In this case the commercial opportunity is in selling hardware, while giving away all the IP for free. You're right that the all-in price of these autopilots tends to be around $300-$350 including wireless telemetry and ground station, although that will fall.
2) More expensive RTF solutions, such as yours ($1,500 without wireless telemetry and ground station) and AttoPilot ($800 now, but probably a similar price as yours for the IMU version) for those who who can't or don't want to get into the mechanics of this stuff (or don't need the flexibility of open source). In this case, you can charge for IP.
So it's pretty simple: the marketplace can choose between cheap and somewhat hard to use, or pay 4-5x more for something that's easier and more reliable, at least in the short term. (Sort of like downloading MP3s for free from P2P sites or paying for them in iTunes.) I'm going to assume that the functionality differences between the two approaches will continue to shrink as the open source world collectively improves the products, just as it did with Linux and Windows. Certainly Paparazzi is technically as good as many commercial solutions.
-
1
-
2
-
3
of 3 Next