What Station?

[Charlie]

Poking through the forum, it's clear several of us are building stations of our own design, and most of us want to use Cumulus when we are done. Since the interface between the station and the computer is likely not designed yet, we could do many different things, including emulating an existing station so that nothing has to change in Cumulus - after all it's not in Steve's best interest to try to support a bunch of "1 off" stations.

So the question arises... to make life easier for everyone, what should we do? Which station do we emulate, or if Steve is willing to create a generic interface, what hardware interface, and what format should we put data into?

Generally serial RS-232 is easier to implement than USB for most hardware amateurs. Even though RS-232 tends to be missing from a lot of recent computers, USB connected serial ports are cheap and easy to find. If USB is chosen, then what interface? The HID interface is a bit daunting for the average software hobbyist. Or maybe not?

How about the data? A defined set (array?) of values with an agreed value for something not implemented, sent in an ordered string? Hex or ascii? Other thoughts? Error checking, or not?

Or has this been already worked, and I simply missed the result in the forum? (wouldn’t be the first time )

[steve]

The 'easyweather.dat' file is slowly becoming a sort of standard general interface, so perhaps the best way would be to not define the hardware interface, but define the interface to Cumulus in terms of that file (or an extension of it).

[Charlie]

That seems like a reasonable way forward. I assume there no risk/issue with 2 applications accessing the file at the same time?

[steve]

I assume there no risk/issue with 2 applications accessing the file at the same time?

There shouldn't be; Cumulus just needs non-exclusive read-only access, and I've not heard of anyone having problems.

[Charlie]

I suspect some homebuilt stations will have extra data - solar, or additional temperatures, or other things - beyond what the Fine Offset stations provide. Does the file format need to be extended to cover those things off? I'm not familiar with the WMR-928, but it has extra channels, so I suspect these parameters might need inclusion, for example.

If we define these extra things in the file format, does that mess up the current generation of Cumulus, or does it simply ignore extraneous data in the file?

[steve]

Yes, we could just define additional fields beyond the existing ones, and it wouldn't affect the existing code.

[rollo]

I suspect some homebuilt stations will have extra data - solar, or additional temperatures, or other things - beyond what the Fine Offset stations provide. Does the file format need to be extended to cover those things off? I'm not familiar with the WMR-928, but it has extra channels, so I suspect these parameters might need inclusion, for example.

<soapbox>If I were to put my IT Enterprise Architect hat on I would be pushing strongly for an interface defined at the logical level as an XML document. As Steve says forget the h/w interface -- that can change adataccording to the needs of specific implementations. The main reason I would require this is that you will need to implement versioning of the interface. If you don't it can soon get unwieldy trying to implement simultaneous change across multiple applications. Benefits include

• If you find an industry standard or a well used schema to base on, half your work is done already. Just add additional nodes for data missing from the schema.
• The interface is self defining
• Checking conformance with the schema is built-in to the parser -- would save Steve heaps of time
• Change is begun by producing a new version of the schema. Implementation can be independent with either the sending or receiving system leading the change.

</soapbox>

I did a quick google for "Weather Markup Language" (you never know your luck). I found Digital Weather Markup Language (DWML) from NOAA, but that seems to be more on the forecasting side. Also found a proprietary API from Wundeground called Weather Markup language which seems to fit some of our data. This may not be usable if Wunderground considers it to be of commercial advantage.

[steve]

Fair enough, but if we're going to design a whole new interface, it's not going to happen for quite some time (if at all in Cumulus 1). I was offering to extend the existing interface because the code is already there, and extending it is quick and easy. I appreciate that it's a hack and ideally we wouldn't do it this way.

[Gina]

Strikes me that the easyweather.dat file would be easy enough to implement and extend. It is in one of the most common general purpose interface formats, after all. Cumulus already supports this so IMO this is the way to go. We would have to agree on what extra data the extended format would represent - eg. my homebuilt weather station adds light level and later I expect to add ground temperature and possibly leaf wetness. I would be happy to conform with whatever extended format is chosen. I haven't yet written the software beyond data logging so sending it to Cumulus would be good.

[Flying Eye]

From a hardware point of view I think I'd favour anything that would be fine with arduino.

I'm not even a novice really but from the reading I did so far that option strikes me as something I may one day be able to figure out and use. All the others look a bit more complex than I could aspire to figuring out.

Is there still any interest from those who have posted so far?

I could see me and another looking into it all, and maybe figuring out some of it between us with luck. I mean someone needs to get started building a station that others could copy or emulate. Could be me and a mate of mine who's got the electronics skills. It certainly looks like a fun thing to do.

It's been too many years since I coded but with effort and luck I may be able to pick up how some of the rudimentary stuff is done. I'd have to look into that.

I don't think Arduino would limit one too badly and it is widely available for not really too much money. I'd imagine it appears to have a good chance of larger uptake for those reasons. I think all the parts are available that could see one with a FO equivalent. I think using their sensors makes some sense at first too. They seem to be able to make that bit more or less OK. (what is the betting it turns out that they buy those bits in?)

From some reading I spotted that some people could actually make an Arduino appear to the machine it's attached to like a joystick controller. That would have to be among the simplest interfaces around and can get quite sophisticated in it's abilities if need be. Seems something to have a look at. I say this as there are a number of compiled basics that could grab the data and lay it down in a file. Not pretty but effective at a very basic level. On a slightly different tack, if pushed I suppose some basic stuff could actually use joystick innards for a directly connected set up, certainly for some of the sensors. There are even wireless game pads which have enough buttons, but lag may be a problem in this setting, one would just have to tinker I suppose.

I think Cumulus deserves it's own hardware where possible. It's mature enough that it could make use of some good hardware, and this whole concept can probably offer that, while still keeping it generally affordable.

[Charlie]

There is certainly nothing wrong with your idea Ian, but it's not a path I'm interested in following. It's purely a personal opinion, but I find Arduino misses the mark for me by using a rather obscure processor and driving you to learn a new (somewhat limited) language to program with. It's too much on an investment for me that is not likely to be reusable.

The weather station I'm working on (far too slowly) is based on a Microchip PIC device. This family has been around for decades and has a host of high level language compilers available from BASIC to C or C++, as well as a vast array of development boards. They are cheap, simple, widely available, and I'm also using them for some commercial designs in my day job.

I suspect there is not a lot of coding to do - basically read the sensors and stuff the data into a form Cumulus can use. Maybe implement a FLASH based buffer so you don't need the computer connected 24/7. But there's no need for a display, or calculations, or predictions... Steve has done an excellent job of that for us.

Good luck with your project - you might even get done ahead of me, or even ahead of Gina who is far faster at this stuff than I am.

[Flying Eye]

Thanks for the info Charlie,

I found last night that there is actually a spark fun weather station v3 board compatible with arduino, they even sell fine offset sensors to go with it.

It's roughly approximate to the 1081 but with a light sensor option too.

Overall it appears to be possible to set them up to handle rs232 serial, ether net, bluetooth, wifi, and XBee. Probably enough for almost any situation. Obviously a lot of reading now needs to be done.

I also discovered that the language is in fact extensible, and the basic arduino boards can now be had for as little as £22.0 or $27.00 US given current rates and sources (Amazon .co.uk and .com as well as spark fun). Some of the board are now available with pretty useful amounts of memory too. Some models having sockets on board for micro sd cards, out of the box.

A huge amount to read up on, but looking very encouraging.