tpms_rx expected output?

[crypticalpha]

Shown in the command line excerpt below, is the output generated by running “tpms_rx” with the parameters as recommended on the gr-tpms github project page. This output was generated over a time period of approximately 40 seconds. A steady stream of the alphabetic character “O” is output to the command line until “ctrl-c” is performed, as shown below by the string “O^COOOOOOOOOrtlsdr_read_async returned with -5” near the end of the above mentioned console output.

Understandably there may not have been any tpms events during this short 40 second time period, however “tpms_rx” has been run multiple times, each for much longer time periods of approximately 1 hour at a high traffic intersection, and confusion about the expected output provokes the questions below.

Does the console excerpt shown below display the expected output to the console by running “tpms_rx”? If not, what is the expected output to the console by running “tpms_rx”?

When running “tpms_rx”, is the data output written to a file, or is the data output displayed in the console? If the data produced by running “tpms_rx” is written to a file, in which directory is this data file located?

---

cryptic@laptop:~/tpms/gr-tpms/apps$ ./tpms_rx --source rtlsdr --if-rate 400000 --tuned-frequency 315000000 linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.002-0-unknown

gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.5 built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy Using device #0 Realtek RTL2838UHIDIR SN: 00000001 Found Rafael Micro R820T tuner Using Volk machine: ssse3_32_orc OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO^COOOOOOOOOrtlsdr_read_async returned with -5 cryptic@laptop:~/tpms/gr-tpms/apps$

---

[Nindjc]

I have the same question exactly Is no one able to answer this question?

[binoculars]

I got the same thing. if you do,

./tpms_rx --source rtlsdr --if-rate 400000 --tuned-frequency 315000000 2> /dev/null

The O's from the error output should be removed.

[jboone]

The "O"s are a GNU Radio artifact which indicates the computer can't keep up with the sample stream from the radio. For those having this problem, can you please describe your operating system and version, and what processor and RAM configuration you're using?

In the meantime, I recommend running volk_profile while your computer is idle. This performs a benchmark that helps GNU Radio choose the optimum signal processing algorithms for your particular processor architecture. This might help to some degree.

[crypticalpha]

Unfortunately running vlok_profile did not help, I am still getting "O" on the command line when I run tpms_rx It is an old laptop that I had laying around and suspected from the beginning that it would not have enough resource. This laptop has the following specs: Make and Model: Asus Eeee PC 1000HE CPU: Intel Atom N280 1.66GHz Memory: 1 GB RAM Operating System: Ubuntu 14.04

[jboone]

Yes, your laptop looks to be a very low-performance machine. That said, there are probably easy optimization opportunities in this project, mostly where the baseband sample stream is filtered and decimated. I will review to see if I can relax host system requirements.

[EdwardMGoldberg]

I know that am pushing the limits here with a PI B2 but I get the same output. My rtl_433 does work 100% so I know that this "could" work. You may want to take a peek that the 433 decoder code. It looks like 40% of the PI CPU when running and reading my WX Sensor Packets.

[jboone]

@EdwardMGoldberg I'm not sure how the rtl_433 project works, but the TPMS code has several simultaneous trees of demodulation -- ASK and FSK, and several different flavors of each. So it's really demodulating a bunch of different sensors simultaneously, multiplying the computational burden. Again, I'm sure there's optimization opportunities, but I don't have a lot of time to focus on it right now, as I'm working on other SDR projects.

[jboone]

Old issue, closing.