Barometer Module

Archive
41

Hijacking alert…

The OLED hardware works fine, AFAICT, and you can safely bet that any display driver Skewworks writes will be awesome. The combination rocks as a great, if little, color display.

42

Caution alert! The 192KB of memory on the Cerberus is not enough for the CP7!

43

@ Ransomhall - Thank you for the confirmation, I have no doubt @ skewworks driver will be great. I have seen some of his work around the forum, really quality stuff.
@ Mike - That is a very good point, I did not even consider that… Thank you!

44

Not all of them bad.

1 Like
45

I agree that some of their modules are fine, but just enough of them have not been to create a whole bunch of doubt. The lack of transparency on what, if anything, is being done about solving the problems is troubling. My comment was some over the top sarcasm to express my angst…

1 Like
46

So what is the current belief about the Barometer modules (v 1.1 ie the current version that is for sale), good or bad? I see they are sold out (supposedly) at Seeed so could that mean a new batch is being made up (perhaps v 1.2?).

47

More likely Seeed has decided to get out of the Gadgeteer module business. Especially when Gadgeteer is a moving target, as it currently is, with 4.1 out for just a bit before 4.2 was released, and 4.3 right around the corner.

Turns out that designing the hardware is easy, especially when you’re not breaking new ground (and four relays on a board is hardly new ground…). The software, however, is non-trivial. Seeed isn’t the only organization having to learn this truth.

48

This is exactly why I’ve become a strong advocate for having module drivers as “real” open source projects separate from the main Gadgeteer project. Gadgeteer core project is too slow to evolve and shouldn’t be reliant on just vendors to move it forward. This is fine for the core code but terrible for drivers.

49

The problem isn’t where the code is kept, the problem is that once the modules are all sold, there’s less motivation to maintain/fix/update/provide-in-the-first-place the drivers. When I buy a random piece of hardware from eBay, I know that I’m getting nothing in the way of software or support. If I buy a Gadgeteer module from Seeed/GHI/Sytech/Love, I expect that the drivers exist, are reasonably bug-free, and will be updated as the Gadgeteer core moves forward. That’s a very expensive proposition for a company.

50

As a module junkie I’m never happy to hear a supplier might be considering leaving the game, but certainly Gadgeteer might not be for them if they just want to be pure hardware guys. Gadgeteer is ultimately about achieving a better balance between hardware and software, but really when we get down to it, software is ultimately the problem and always has been (always seems like there is hardware ready to go that needs software), but that was the objective of Gadgeteer was to bring more software guys into the game by wrapping hardware modules in the software needed to use them and I still think that is way to go and I hope and trust for example that Gadgeteer is working out very well for GHI Electronics and I would think that Gadgeteer is a sweet growing market space for those interested and capable.

What were the hardware differences between the V1 and V1.1 barometer modules? Why the change? Why did it cause the problem as the V1 modules that I have seem to work great (ie what broke). Is GHI still selling the V1.1 module as I would be interested in getting one for testing and see what the heck happened (I have my doubts this is a software problem).

Seeed has a number of really good modules so I hope someone will continue to make and sell those if they decide to drop out (I’ve certainly given them some encouragement to play in this space), but this is only rumor at this point that Seeed might be exiting, important to remember that.

51

I agree on the hardware/software comment. This is why we decided to use this test “where hardware meets software”. See the gadgeteer “light bulb” image http://www.ghielectronics.com/catalog

52

Gus,

Where does hardware meet software for, say, your XBee module?

53

To me (at least) I use xbee a simple point to point connection with no commands whatsoever, 2 xbee board establishing connection on their own. But if a user wanted to take advantage of the other features bee has, they can use http://xbee.codeplex.com/

This can apply to all modules. The driver must enable developer to use modules and then still let them expand with what their requirements are, which every project have special needs.

54

How about the Bluetooth module? The only functionality it provides is a property that tells whether or not it’s connected, and it’s not clear that that even works. For a $40 module, I’d expect more.

The point I’m attempting to make here, is that Seeed isn’t the only one that’s guilty.

55

Yeah, that one is still missing. We are very excited that we have accomplished so much (modules, firmware, open source…) in such a relatively short time, but this kept us too busy. What we are doing now is revisiting all drivers and libraries. If you or anyone have comments or wish list then this is the time to bring it up.

56

I don’t think you can count a module as an accomplishment before you’ve released a working driver. Especially in the Gadgeteer world, things are supposed to be “plug-and-play”, like the camera/button demo. The XBee driver does NOT meet the standard. The Bluetooth driver is an actual joke on anyone who spent the $40 on the module.

The really sad thing is that prominent forum members put a LOT of work into an XBee driver for you, but it’s nowhere to be found. Someone built a kinda-driver for the Bluetooth module, but it’s also MIA.

I can’t say I speak for anyone but myself, but I do think that GHI should focus on making what they’ve released into high-quality offerings before rushing out more buggy hardware and unfinished software. I’m sorry, I really respect GHI, and I’m a dedicated customer, but this is my opinion. I’m willing to take the discussion somewhere else if you wish to continue to discuss it.

1 Like
57

Thanks for feedback

58

You guys have been pumping out a lot of great hardware lately. Not only that, you have been working to lower the cost by improving (ie spending time & $$) your infrastructure.

What seems to have changed of late (or at least my perception of it ) is that this has become the prime focus. Whereas when I joined GHI offered great hardware WITH great documentation/samples/etc.

3 quick examples of modules that have been offered for atleast a year now:

Seems (being the operative word) that there’s more scrounging for information now than in the past. Prior you were more focused on the entire solution/big picture.

Thankfully for the community you setup and fostered, I’ve learned alot and have be more self-sufficient. I came for the Domino boards, and I expected the learning curve. But people coming because of Gadgeteer, as godefroi pointed out, are expecting PnP.

Don’t want this to seem like bashing, again like godefroi, I love the stuff you put out. I continue to be amazed by the pace of your innovation, but that needs to be balanced out a bit more, imho.

59

I’m suggesting that we should not necessarily expect hardware manufacturers to also be good at software. The fact is there are a lot of good pieces of Gadgeteeer hardware that have IMO poor software. I think there are lots of people such as myself that are willing to help out with the software if it’s not too much hassle to do so and we feel like we’re “part of the team”. The current Gadgeteer Codeplex project doesn’t really foster this well in my opinion.

I have been personally tossing around the idea of starting my own community project to create drivers for many of the modules that I’m not happy with. If the vendor chooses to pick them up and use them then great. If not, then I’ve still got a great piece of hardware with a (hopefully) even better piece of software to drive it. Of course, the vendor should be willing to help out on occasion when needed.

The reality is that software is expensive to create and support probably much more so than the hardware. If I had the option to buy a module for $25 and use community provided software vs paying $40 for the same module with starter software provided by the vendor then I’d buy the $25 version almost every time.

60

I absolutely agree. I’ll go one further and say that while the current CodeShare implementation is worlds better, it still falls short. Maybe what each module needs is a CodePlex project of its own. That way you get issue/feature tracking (which is HUGE, and something I’ve suggested several times), revision control, and documentation tools.