Archived Forum

I suggest that you locate a spec sheet for the unit, or contact the manufacturer.

Paul

I have a spec sheet, for what it's worth, but it doesn't give answers to any of the above questions. I have written to the manufacturer, but I doubt they will answer me, because using their sensor in a DIY project is probably not something they would welcome, and would certainly not wish their staff to be taking time answering detailed technical questions. Usually when asked this type of questions, product companies answer "we have no documentation on that, and the guy who designed it left years ago".

We will see what comes back from the manufacturer! But I suspect  have to rely on finding someone who has managed to puzzle this stuff out before me, or do it myself.

Rowan

It can be difficult! I had a similar problem where the company concerned refused to give me any technical information, claiming it to be intellectual property...

Paul

Any news about that? I'm trying to do a similiar stuff, receiving the Apollo sensor rf signal with an rfm01 and arduino.  Actually i've found the following information that can be usefull:

- The same electronics (sender, receiver) are used in 'The Rocket Sensor' and "Whatchman Sonic " (i'm using the second one), but i cannot retrieve other information

-  Modulation used in transmission is FSK (my RFM01 receiver has the same SI4320 rf)

-  "pairing" the sensor with the receiver starts a continous data transfer, maybe for sync, and offers a good way for testing communication (i'm using a magnet to put the sensor in "pairing mode)

- each transmission has a duration of 0.140 sec and has 140bit of data (maybe 1000-1200kbps), the first 16 bit (but i'm not shure)  are the same in each transmission, so i think is a sort of header, that reduces the "data" bit to 124, probably 31 nibbles.

- transmission frequency I supposed is 433.9Mhz (in my case I have two peak at 433.87 and 433.93)

- watching radio scheme i've seen 18 peak/oscilation for bit value 0 and 86 peak for bit value 1 (probably is not a precise measurements, i've used rtl-sdr + audacity for signal view)

I hope that can help us to find a way to get sensor data

P.S.: my receiver is broken due to power faults, opening it is so difficult, it appears to be glued. With a functional one i think it's possible to read what the receiver pic sends to the Si4320 fsk receiver. By pin configuration I think it uses SPI for communication and connecting an arduino can be a way to grab what pic sends to Si4320, that's probably all the configuration data (frequency,data rate, mode, etc..), take a look at SI4320 datasheet.

Thank you very much for your reply. It's great to find someone who is trying to do the same stuff that I am! I'm afraid that I haven't made much progress with my project (not as much as you). What you have discovered is certainly useful. Can you please give me full details about how you set up your RFM01 and what mode you used it in, to get those 140 bits of data? I would like to set up the same arrangement and then see if we can puzzle out what those 140 bits mean, and how to decode them into an oil level reading.

Please can you tell me what I need to do to duplicate your results? I guess I need to buy an RFM01, which I see that I can do for GBP 4.48 from Farnell. Have you written some Arduino software to configure the RFM01 correctly and to receive and decode the data? If so, would you be prepared to share this with me? If so, I guess I need to buy an Arduino - which model exactly? My preference would be to use a Raspberry Pi since I happen to have one here waiting for a project :-).

How does the RFM01 need to be set up to work with the Apollo transmitter? Presumably we need to set up:
 - the configuration settings (including the frequency band, the bandwidth, the crystal load capacitance etc.)
 - the frequency or channel number to use within the 433MHz band.
 - the receiver settings (including VDI mode, LNA gain, RSSI detector threshold).
 - The AFC settings
 - The Data Filter settings
 - The Data Rate setting
 - The FIFO setting

Presumably these things need to be set up via the SPI bus. How did you set yours up? Did you write any code to do this?

Would you be prepared to send me your 140 bit string that you received from your device? Then I can try to puzzle out what the bits mean. I imagine that there must be some kind of signature in the string, which the receiver uses to ignore 433 MHz signals from devices that are not Apollo oil tank transmitters, and signals from other oil tank transmitters that your neighbour might have on their tank. I imagine the in "pairing" process the receiver learns this signature, and thereafter ignores transmissions that do not have the correct signature.

Have you been able to capture the regular transmissions that the transmitter makes (I guess about once per hour) of the current oil level?

What is  "rtl-sdr", that you refer to using with Audacity to read the data?

I would like to get myself to the same point that you are at as quickly as possible, then we can try to work out the format of the data within the string of bits that we are receiving. I have two Apollo transmitters here, so that should help.

Thanks - Rowan

Sorry, actually i haven't found working RFM01 settings, I've retrieved all the previous information by watching the signal waveform.  rtl-sdr is a software defined radio based on dvb-t tv usb dongle (the cheapest way for inspecting radio signals), with sdrsharp I can view any signal from 52 to 2200 Mhz, and record it. Opening the recorded signal with audacity shows the waveform of the transmission.  Watching the apollo signal it I've seen that it is fsk (but I already known that, by SI4320 datasheet), and assuming that high signal frequency is "1" and low  "0" i can identify each bit of transmission and count them. I can also view the total duration of the transmission and the single bit duration. 

With RFM01 I've tried with the more matching settings but without result: band 433, frequency 433.9 (center between 433.83 and 433.97)  and directly 433.83 and 433.97, for the other settings I'm trying all the combinations, but it requires a lot of time.

For the RFM01 there are these arduino library https://myfablab.wordpress.com/2010/06/22/rfm01-and-rfm02-libraries-for-... (opening the library with notepad++ shows all the method you can use but my preferred one is "trans" that accepts directly the configuration code). 

Configuration code can be generated using the silabs tools at http://www.silabs.com/products/wireless/EZRadio/Pages/Si4320.aspx

My next step is trying with an RFM12B or RFM02 (RFM01 is a receiver only, RFM12B is both receiver and transmitter, RFM02 is a transmitter only) because I want to check if there is a frequency offset  in my measurements and trying to reproduce a similar signal. The "idea" is to generate a 140bit signal (probably the already retrieved sequence of 0 and 1), adjusting transmission frequency until it comes over the apollo transmission and then compare my transmission with the apollo one and make changes to the settings (step by step) until i get a perfect match between the two transmission. Use that settings in RFM01 and see if i can get some data and then adapt the RFM01 library to 4bit packet (actually is 8bit) or a single 140bit stream... The reason is that i can't know what's wrong with my receiver, it simply doesn't receive nothing, but with a transmission i can see the difference between the two signals and correct the difference..

When I will get data with the RFM01 and arduino I think it will be simple to decode what is transmitted, probably (hoping that the signal is not encrypted) is a simple number. I know that the  calculation are made by the receiver unit (dip switch for settings the tank size), so the transmitter sends a value that can be the measured distance or the ping time (looking to the poor transmitter electronics i think is the second one)

[Two more copies of this post have been deleted - see "NEW USERS, PLEASE READ - Posts held for moderation"]

Thanks for your reply.

Thanks for the info about rtl-dsr - a whole area of modern technology that I was unaware of! My thoughts about this were to see if I could see the 433MHz signal on my oscilloscope, but it probably would never have worked, since it is only supposed to have 100MHz bandwidth. Your approach sounds better, if a bit long winded.

I have not tried hard to open up my receiver (which works fine) because I did not want to damage it. As you say, it seems like it is glued together. I suppose that in there there is an SI4320 and a microcomputer of some kind, and I suppose that they communicate via SPI. Might it be possible with a working receiver to monitor the SPI communication and capture the setup commands that the micro must send to the SI4320? That would give a set of settings that could presumably be sent to the RFM01 and would then receive the signals from the Apollo transmitter correctly.

As you say, all the processing to create the tank level seems to be done in the receiver. Like you I am expecting the transmitter to send just a number, which is presumably a count of some clock for the length of time to receive a reflected ultrasonic signal from the surface of the oil. I am hoping that maybe the resolution of this reading is finer than the 1/10 of a tank resolution of the receiver display, which would enable better/faster readings of oil consumption to be calculated.

Maybe I just have to break or hacksaw open my receiver, and see if this appears possible. Then I would need to design something that will monitor and decode the SPI signals without disrupting the operation of the receiver. Does not sound impossible with a little micro of some sort. Maybe it could even be done by monitoring the signals on my scope.

That's as far as I have got for now. Please let me know if you progress farther!

Thanks - Rowan

Another idea: there are not that many channels in the 433MHz band (69 in fact). Could we not simply try them all to find out which one receives the signals from the Apollo transmitter best? A C program could potentially do this automatically with the transmitter in "continuous transmission" mode.

Rowan

Unfortunately my receiver is incredibly damaged and I can't make the spi test, however the SI4320 is connected to a PIC16F630. Referring to the SI4320 datasheet,the connection with PIC are in SPI mode (the SI4320 could work in standalone mode but following the wiring I think this is not the case), and it's easy to identify MOSI, MISO, SCK and SS (in SI4320 datasheet there is a full connection diagram).

The receiver is glued or soldered, mine was already broken so I've used hard manners for opening it. Probably using a little cutter is possible to open it without evident damage.

About che transmission channel I think that is only a small part of the problem, knowing the channel but not the data rate doesn't produce any result (or bad result, with that approach I have believed that I've found the signal but it was from another source..)

A good but very challenging idea (for me) is this: https://hackaday.io/project/1548-rocket-receiver-teardown 

Make a script that tries all the possible RFM01/Si4320 settings combinations, but I think it is more complicated

I got a spare receiver and tried to hook it up to sniff the SPI traffic, but unfortunately I was being too impatient — rather than waiting for a proper SOIC chip probe that would clip on, I was trying to use normal probes. And in the process I blew up both my receiver and the Bus Pirate I was trying to do the sniffing with.

Still, the information above should be enough to get us a lot further. If you see peaks at 433.9MHz ± 30kHz, that implies that the baseband bandwidth (bits i0-2 in the configuration) should be 67kHz, surely?

That's probably all we need to care about to get started. Stick a magnet on the transmitter to make it stream data constantly instead of only chirping every few minutes. With a simple SI4320 we could monitor the ARSSI output of the chip to see when it's getting a signal, and we can fine-tune the frequency (and perhaps set up AFC). However, the RFM01 module doesn't give us an ARSSI connector. Is it actually using a Si4320 on the module, and if so can we still access the ARSSI pin even though it's not brought out to the external connectors? (I've ordered some RFM01 modules but mine haven't arrived yet.)

Otherwise, we'd have to use the digital RSSI — set the VDI bits (d0-1) to zeroes to enable the DRSSI to be output on the VDI pin, then use that for fine-tuning the receiver. Probably starting at the lowest trigger level (bits r0-r2) and increasing it as we get closer to the optimal settings. Probably set the LNA gain somewhere in the mid range and tweak it only if we need to.

Then we can move on to the data rate. There are tens of possible data rates in the 1000-1200bps range, and it's probably not impossible to just try them.

I'd stick with the polled mode, where you just clock data out directly whenever the FFIT pin goes high. We can set up the FIFO later; that's purely a software construct between the receiver and the host, and not really what we need to work out here.

FWIW I've also had a response from Dunraven Systems. They're not interested in helping:

"Unfortunately David the information you ask for we are unable to provide as we do not operate an open protocol - I would suggest that you make contact with our business manager to discuss this further. "

Oh, rtl-sdr is a wonderful thing. How did I never find *that* before?

So rtl_power shows peaks at 433867 kHz and 433925 kHz which go away if I stick the transmitter in the microwave. That's about 60kHz bandwidth, at 433.895MHz.

Capture that with 'rtl_fm -f 433895000 -l 140' — result at http://david.woodhou.se/watchman.cap.

Import it into Audacity and you can see a nice clean waveform. I'll see if I can show it here...

I think I now see where you got your 140 bits in 0.140 seconds. But I wouldn't interpret it like that. My first guess would be that it's a Manchester encoding — so a 0 bit is indicated by a transition from low to high frequency, while a 1 is indicated by a transition from high to low (or perhaps vice versa).

The start of the frame is indicated by three high half-bits followed by three low half-bits. And the end of frame is marked by repeating the last half-bit two more times.

I count 64 bits of data, in that case. So (decoding by hand, so expect some bit errors) the data in the packet I showed above — when it eventually makes it past moderation and shows up — was D73929E27EBFAE7C. Which will contain the unit ID, the current measurement, and also some indication of the battery status. And maybe a CRC or checksum of some kind.

I'll throw together something to decode them by hand and see if I can make further progress....

I've been posting updates in the project at https://hackaday.io/project/1548-rocket-receiver-teardown because they're not delayed by moderation there. One more update here though...

At http://david.woodhou.se/watchman-demod.c there is a program which works with rtl-sdr to receive the signals. Looks something like this:

The signal decoding is a terrible hack. I felt less ashamed of it when it needed precise tuning and only worked with one unit at a time; now I've made it a little bit more robust it's just more obvious how bad it is :) 

I'd like to throw out my own signal decoder and use something else — there must be an open source one we can use which will adapt properly and be more robust. But this works OK as a proof of concept.

I've now added support for these devices to rtl_433: https://github.com/merbanan/rtl_433

However, although the signal processing is now Not My Fault™, it's not perfect — the reception at long range was better when I was using rtl_fm: https://github.com/merbanan/rtl_433/issues/223

A quick screen shot using the setup described at http://www.domoticz.com/wiki/Lua_-_Oil_Tank_Monitor

The RF signal process is a lot better now, FWIW. Tommy Vestermark has done a lot of work on the FM decoding and level detection, and it's much more reliable. I've been using this "in anger" for a while now, and it's doing a really good job.