Were to get raw data in linux from recieved signals usingduo

[Iznogood]

Read a lot of post in the net according collecting data from a duo installed in linux ( Ubuntu 12.04 LTS ).
Almost everyting worked synaptec crashes thoug when inporting the gpg key but cli are no problem.
I can turn on and off units the little duo flashing when sending and if I press a remotecontrole it flashes and entries are created in syslog as sighups.
But were are the recieved data?
Just to confirm that things are working?
possible to tail -f some device?
Written entries in a file?
I am not a programmer so if you suggest any script plz suggest me a complete one just getting the recieved string out and how to execute it.
Tried som python snippets i found on the net just complaining on syntax so they were probably written of sombody like me.

A hand plz?

[Iznogood]

Found some thing interesting in the doxygen.
If there are an example code in C for the Linuxplatform I will be more than happy.
Just getting the raw data out from the duo.
There were no exaple for these two sections in the page.

Regards:
/Iznogood

RawDeviceEvent

Use this callback with caution. It outputs everything from a TellStick Duo without any preprocessing. This can be used to get events from devices not already configured.

Parameters:

const char *data - raw device data
int controllerId - id of receiving controller, can identify the TellStick if several exists in the system
int callbackId - id of callback
void *context - see Registering for callbacks for description

SensorEvent

This event is fired when a new sensor value is retrieved.

Parameters:

const char *protocol - The sensors protocol
const char *model - The model of the sensor
int id - The unique id for the sensor.
int dataType - Flags for which types of data the sensor supports
const char *value - A human readable string of the data
int timestamp - The timestamp when the latest value was received
int callbackId - id of callback
void *context - See Registering for callbacks for description

[Iznogood]

I never done python earlier and I had no clue on my transmitting devices so I went desperate and and did a python blind run.
My problems with my earlier Python tries were the interpreter version.
Found in the forum 2.5 or higher to work.
So an excellent guy ( davka003) wrote a wrapper with functionality who have should been in the tdtool, the magic of -t
http://www.telldus.com/forum/viewtopic.php?f=15&t=2109

Download an acrchive of td.py and tdtool.py ( td.py are referenced from tdtool.py ) from bitbucket.

Then you can look and get a hunch of what's in your sorrundings.

Do not forget the version of the interperter.

On Ubuntu 12.04 LTS ( with added python ofcourse )
python2.7 ./tdtool.py -t

I have a question to micke.prag why not include the same function in tdtool or at least give a c/c++ code sample?
Maybe with more detailed data like -tb ( -t with binary dump raw signals should be possible to get from the Duo and you guys have exclusive knowledge to the hardware )?

-Share?

Greetings to davka003!!

[davka003]

Thank you very much for your kind words. Perhaps I should update the printouts somewhat to include the data in raw format (today I print the string as received by libtelldus and I am not sure if it could be anything but printable chars - haven't seen any pure binary yet at least).

Suggestions on inprovment are very welcome! (as is pull requests

[Iznogood]

If it is possible just add an -td switch then the user could chose what they want to see.
The thread has been a lot of silence in from ordinary tellstic representatives I do not know really why?
The feature of identifying what is transmitted should be more common.

You buy a set of transmitters or recievers and before you can use them you must configure them but if you do not know what to configure??
I.e I had a Nexa module ( the brand of brands or at least sells a lot ) who worked just excellent with the remote.
Worked just perfect from the old tellstick and the duo when act/deact from the computer BUT the ON signals from the remote were not detected by the duo.
First thought its the duo BUT it was not.
On this particular piece the center frequence on the transmitter were just slightly not as other Nexas ( ocilloscope ) so thats why things did not work.
The recievers accepted the signal but the duo did not because it were not as the specification.
Then it is good to look and see what's wrong and -t in your script made it possible to exclude a lot of error sources.

So even better?
If the libs and the firmware will be published open to the duo?

[davka003]

I am looking into this raw service data but it seems like "raw" data when it comes to Telldus is quite much preprocessed. My python implementation outputs what is received on the libtelldus API, it doesn't seems to be any way of having the duo spitt out something that resembles sampled rf data. It would be realy interesting thou to have such a firmware as that would make it possible to make new device support just by writing signal processing functions in whatever language you prefer.

[krambriw]

Maybe having duo being able to do something like this would be awsome:

http://wiki.nethome.nu/doku.php/analyzer/start

I'm using this tool but not with the duo...

BR Walter

[davka003]

Yes, I would love to be able to use the DUO as a radio receiver for such a tool. But I assume that would require quite some changes to the responsibilites between firmware and host software compared to how it is done today. I dont even know if the PIC in the DUO and the USB transmission circuits are up for the job.

This would also make it possible to make much more advanced signal processing and thus probably increase sensitivity on receive side (if enough programming effort and cpu cycles in host is spent on signal processing).

Micke Prag is this anything that exist in the telldus experimental / development tool box? (If I would have developed the DUO this is the firmware I would have started with if possible to be able to make sure that all radio circuits are working and ease the development of new protocol support)

[davka003]

I have now corrected some very obvious bugs in the handling of callback for sensordata events. The problem is that I dont have any hardware to test this functionality so everything is completly untested. Any feedback if sensordata works would be nice.

[oroulet]

I would also like to get raw data from the DUO if it is possible.

davka003,
I have sensors and your -t flag work fine with the latest version. What kind of feedback are you looking for?
As expected the raw data only shows the supported sensors, even if I have several other devices sending wireless data at 433.92 MH

1343908211: RawDeviceEvent: class:sensor;protocol:mandolyn;id:12;model:temperaturehumidity;temp:21.1;humidity:54;
controllerId: -1
1343908211: SensorEvent
protocol: mandolyn
model: temperaturehumidity
id: 12
dataType: 1
value: 21.1
timestamp: 1343908211
1343908211: SensorEvent
protocol: mandolyn
model: temperaturehumidity
id: 12
dataType: 2
value: 54
timestamp: 1343908211
1343908211: RawDeviceEvent: class:sensor;protocol:mandolyn;id:12;model:temperaturehumidity;temp:21.2;humidity:54;
controllerId: -1
1343908211: SensorEvent
protocol: mandolyn
model: temperaturehumidity
id: 12
dataType: 1
value: 21.2
timestamp: 1343908211
1343908211: SensorEvent
protocol: mandolyn
model: temperaturehumidity
id: 12
dataType: 2
value: 54
timestamp: 1343908211

[davka003]

Thanks for the feedback, with that output it do seems to work fine.

I got my DUO the other day so I have been trying this as well in my own home, but just with a single sensor.