Topic: Any interest in a new product?

[aweatherguy]

I am trying to gauge how much interest there might be in a small reciever for (mostly) Oregon Scientific sensors. To sell commercially in the United States, I would need to spring for FCC emissions testing; that's probably around $5,000 if the process goes smoothly. With that kind of outlay I would like to have some idea of potential sales before I go ahead with this.

For now I'm only considering US sales; I have not looked into regulatory requirements in the EU yet so if that happens it will be later.

A tentative data sheet is shown in the image attached to this post.

The selling price (very tentative) would be in the neighborhood of $50-70 without the antenna and $70-90 with antenna. Including the antenna is mostly just a convenience and folks would maybe save a few bucks buying or making their own antenna.

If there's enough interest, I would later be looking for a very small number of beta testers who would purchase a prototype unit at a discounted price, and provide feedback on using it with one of the listed weather station software apps.

Comments and suggestions will be very much appreciated!

[Old Tele man]

Would those be *older* generation OSI single-frequency sensors (Protocol 1, 2.1, 3) or the *newest* WMR300 OSI frequency-hopping sensors?

[aweatherguy]

This runs only at 433.92MHz -- so the new 900MHz WMR300 sensors are not included. 

[nincehelser]

I'd be very interested if it can grok Acurite's 433MHz signals and works with Linux.

[aweatherguy]

Which Acu-Rite sensors are you using (model numbers)? Right now, it can receive a couple of them and might be able to handle others.

The unit just spits out ASCII data over USB (looks like a COM port on Windows). The data format would be "open" -- published in gory detail. What might be of more interest however would be the translator app that re-formats the data for other weather apps, as it takes some of the headaches out of dealing with the USB data stream.

If there's enough Linux interest, the app that translates the receiver's data stream to inputs for other weather apps could be made to run on Linux. What weather station app do you use on Linux?

[nincehelser]

Which Acu-Rite sensors are you using (model numbers)? Right now, it can receive a couple of them and might be able to handle others.

The unit just spits out ASCII data over USB (looks like a COM port on Windows). The data format would be "open" -- published in gory detail. What might be of more interest however would be the translator app that re-formats the data for other weather apps, as it takes some of the headaches out of dealing with the USB data stream.

If there's enough Linux interest, the app that translates the receiver's data stream to inputs for other weather apps could be made to run on Linux. What weather station app do you use on Linux?

The Acurite 5n1 sensor 06014RM
The Acurite Tower sensor 06002RM / 592TXR

I'm not sure those model numbers are correct.  I got them from the web site, but they're currently making changes.  Basically if you cover the 5n1, 3n1, and Tower, you've covered the bulk of their sensors.  (They do have other sensors, but they aren't "AcuLink" compatible and don't seem to get a lot of attention.)

I use weewx with a custom driver and some scripts to read data from an Aculink Bridge via the network connection.

It would be nice to have an open option to the Aculink Bridge.  I don't think the receiver is quite as stable as it could be. 

Are you planning to process the raw radio signal on your device, or is that up to the computing host?

[aweatherguy]

Thanks for the model number. I'll look into that but if they are on 433.92MHz it should not be a problem.

The rest of this post is pretty technical...those not interested in Linux/weewx may want to skip!

The unit decodes on-off keyed radio signal packets into bits. It determines what kind coding is used (e.g. Manchester vs Pulse Spacing) and knows how to recognize packets from the OS and Acu-Rite units listed on the data sheet.

For each packet, the output indicates the type of transmission (e.g. OS version 2.1 or Acu-rite) followed by the decoded packet bits in ASCII-hex form. The host must then make sense of those bits; converting them to temperature, RH, wind speed, etc. That's the purpose of the translator app. The USB output is documented and you could also write your own translator/decoder app if desired; I'm thinking that most folks won't want to do that but there's no good reason to hide the information required for the task.

As an aside, there's not really enough code space in the processor to decode the packets into temperature, RH, wind speed, etc. Being able to handle all the different physical layer formats (with room for new formats too) takes a lot of code and there's not really enough room left to decode data to final values. Also at some point, the processing power in a 4MHz Atmel processor becomes an issue.

To interface with other apps on windows, the translator app does one of two things as of now. VWS and Cumulus are configured as "stationless", and they poll/read data from a file which the translator updates as data is received. For WD, the translator writes data to a virtual COM port so that WD thinks it is getting data from an home-brew Arduino station over USB.

To make this work with weewx, I would need to do some more research. At first glance, it does not seem to have a "generic" or home-brew/Arduino mode.

The easiest thing would be to have the translator app feed data to weewx through a local TCP/IP socket, pipe or file. Otherwise, I'd need to have a COM port emulation that would trick weewx into thinking it was getting data from a real USB or Serial port.

The socket/pipe/file option would be pretty easy to implement if I had access to a data format document on one of the supported weather stations. Emulating the COM port on Linux might be a lot of work and might be the least preferable option.

[aweatherguy]

Forgot to mention...the photo in the data sheet is of a real, working prototype; the only thing between that and a commercially available product is the FCC testing and final packaging (logos and such).

[nincehelser]

I wouldn't worry about weewx.  The way the software was written the author expects users will write the "drivers" for specific weather stations. 

From a Linux/Unix perspective, I'd be satisfied the just a data stream or file.  Like you said, that would be easiest, and making it look like a comm port ala Windows isn't really necessary.

From your description, I'd just run your output through some scripts to make them "human readable", then feed that into weewx, making the weewx driver pretty minimal.  That's what I do now with the Acurite Bridge.