I'm looking for an easy solution to identify data formats, protocols. I have an outdoor temperature - humidity sensor which is connected to my HVAC system. I want to decode the data coming back from the sensor into another processor. I do not know the format - protocol and can not get any documentation from Honeywell. Short of buying a protocol analyzer are there any software solutions out there? is an example of 40 deg. F with 53% humidity.
Like jpc says, you have to know what the protocol is the use a protocol analyzer. Most protocol analyzers are rather generic, so it may be hard to find an analyzer that decodes a possibly proprietary protocol.
What I do in a case like this is have a look for specifics in the first screenshot you have. What I find striking is that there are a few very narrow pulses, which will probably 1 bit-time wide, but then most other pulses are several multiples of this, so that would be longer sequences of
0s. That's odd, but may be noteworthy.
Next step: make more measurements and compare them. Are there partial sequences which return every time? If yes, these could be preambles and postambles defining data frames.
When looking in a data frame it's time to guesstimate. Write down what bit sequence the data could represent, just guessing and using your imagination. If you have a measurement just slightly differing from the previous one, like 41° instead of 40°, that's a good opportunity to look where this shows in the pattern. If the leftmost part is the same, but at the right it looks different, then humidity will be sent first, and maybe also MSB first (Most Significant Bit).
From now on it very much depends on what kind of correlations you can find. I would look for the wide pulses, because I'm a bit puzzled by them. Do they really represent for instance 8 consecutive
1 bits like I presumed based on the narrowest bit? If yes, you would expect to see these pulses to be broken sometimes, having some
0s in them. If it never changes they may represent the highest order bits in a 16-bit word (or longer), which may only change if you're going beyond 100°.
That's all I can say without having more samples. I hope it's a start.
A protocol analyzer will not help if you do not know what protocol it is (and it may be proprietary).
Reverse engineering serial protocols is a little tedious but also offers lots of fun and satisfaction (if you get it right).
If there are no more wires going between the devices then chances are that this is a standard asynchronous serial transmission (UART, RS232). Look out for the 9-bit variations which are sometimes popular in embedded systems.
A logic analyzer (like the Saleae Logic) may be better suited for this job then an oscilloscope but either way it ultimately is up to you to figure it out.