I am trying to control a Philips tv via the rs232 port. Currently I am doing this by communicating with a raspberry pi. Using docklight (a windows program that allows the sending of sequences) I am able to successfully control the tv. I spent a fair amount of time messing with the exact syntax needed to pass a duplicate string from my raspberry pi (as it appears in docklight or when I cat /dev/ttyACM0) so it seems as if the right hex commands are being sent but the tv does not respond to any code that I send to it. This is the command that I am currently trying:
echo -ne '\x05\x01\x18\x02\x1E' > /dev/ttyAMA0
All baud rates and similar settings are appropriate (9600)
I'm at a loss at where to go here. The only thought I have left is that there is some sort of voltage issue between the pi and the tv that doesn't exist between the desktop and the tv, but that's a bit of a longshot I believe.
I had the same problem. Turns out that newer Philips TVs require a Group ID at byte 2.
You can set this to 00.
This affects both the first byte (message size) and last byte (checksum)
Example
OLD FORMAT -L GETPOWER [ msglen ] [ display id ] [ command ] [ Checksum ]
04 01 19 1C --> This results in no response at all on newer Philips TVs
NEW FORMAT [ msglen] [ display id ] [ group id ] [ command=19 ] [ checksum = XOR ]
05 01 00 19 1d
Related
Trying to read data from a COMn: port using FreeBasic. The device is a TouchScreen with an ARM controller that punch serial data at 9600,N,8,1 via a FTDI chip to connect USB to PCs. This motherboard I am using for test has native COM1 on BIOS, and for some reason Windows blocked COM2, 3, 4, 5, 6, 8, 9, 10... Upon connecting this device to the motherboard it enumerates USB and allocates COM7: for that on Device Manager. Putty program can read it as COM7 nicely when interrupting the infrared matrix on the touchscreen, and shows incoming data as AxxxyyyZ, where xxx and yyy are the coordinates 1~600 and 1~800, Z is "B" when interrupting, "N" when lifting and "C" when draging, and the initial "A" is just sync.
Pretty easy to write a code in FreeBasic to drawn circles where touch, and line when dragging, right? yes, except FreeBasic could not read COM7: for nothing in this world. It opens, there is no error on OPEN "COM7:N,8,1" as 1, but no data could be read from Windows.
I suspected FreeBasic has some issues with COMn: when "n" is higher than certain value. So I literally destroyed COM2 on Device Manager, and after few restarts I could see COM2 free on Device Manager and allocate 2 to this FTDI connection, and voilá, working.
It might be something else, I don't know, but as COM2 it works. I could not find on FreeBasic literature about some limitations for COMn values... Does anybody knows something?
The correct way to use Serial Port with FreeBASIC you can see below
OPEN COM "COM7:9600,N,8,1,dt" AS 1
The main parameter is a String that describes, at the very least, which communications port to open. It has the format:
"Comn: [ baudrate ][ , [ parity ][ , [ data_bits ][ , [ stop_bits ][ , [ extended_options ]]]]]"
where,
n
Com port to open. "1", "2", "3", "4", etc. Some platforms will support more serial ports depending on how the operating system is configured. Where n is not given, "COM:" will map to "COM1:", except on Linux where "COM:" maps to "/dev/modem"
baudrate
"300" (default), "1200", ..., etc.
parity
"N" (none), "E" (even, default), "O" (odd), "S" (space), "M" (mark), "PE" (QB-quirk: checked, even parity)
data_bits
"5", "6", "7" (default) or "8".
stop_bits
"1", "1.5" or "2".
What I want to do:
I want to connect my Raspberry Pi 2 to a Bluetooth Smart Weight Scale (Medisana BS440) and receive my Data.
What I know:
There is just one interesting Primary Service with 5 Characteristics:
- handle: 0x001a
- properties: 0x20 (Indication), char value handle: 0x1b uuid:00008a21-0000-1000-8000-00805f9b34fb
- handle: 0x001d
- properties: 0x20 (Indication), char value handle: 0x1e uuid:00008a22-0000-1000-8000-00805f9b34fb
- handle: 0x0020
- properties: 0x02 (Read-Only), char value handle: 0x21 uuid:00008a20-00..
- handle: 0x0022
- properties: 0x08 (Write-Only), char value handle: 0x23 uuid:00008a81-00..
- handle: 0x0024
- properties: 0x20 (Indication), char value handle: 0x25 uuid:00008a82-00..
I used the HCI-Snoop-Developer-Funktion of my Android-Phone, to see how the corresponding app communicates to my scale.
Write 0200 -> 0x1f (enable Indication 0x1d)
read 0x21 -> 0x21 (value: 37fb)
write 0200 -> 0x1c (enable Indication 0x1a)
write 0200 -> 0x26 (enable Indication 0x24)
write 02a31e2c0b -> 0x23 (I don't fully understand this here, but I know if you take the bytes after 02 (a3 1e 2c 0b -> 0b 2c 1e a3 -> this is the current Unix-timestamp but for the year ?1975?)
after step 4. there is the first Indication (handle 0x25) which give me the stored personal data of me (my height, gender, age etc)
after step 5. there are some Indications (handle 0x1b and handle 0x1e) which should transfer my measured data. (Didn't analyze the hex-values at this time)
What I did:
I installed bluez.5.32 on my raspi (kernel 4.1.13), and did step 1 - 5 with gatttool and everything works fine till step 5. I don't get any Indication-messages from handle 0x1b and 0x1e) Nothing happens after step 5.
gatttool -t random -b DE:70:4A:XX:XX:XX -I
char-write-cmd 0x1f 0200
char-read-hnd 0x21 (37fb)
char-write-cmd 0x1c 0200
char-write-cmd 0x26 0200
char-write-cmd 0x23 0000000000
(I even do the thing with unix-timestamp-for 1975.. doesnt worked out)
After billions of hours I was getting bluetoothctl work on my raspi (there was a dbus-problem) and I tried the same with bluetoothctl. I enabled all Indications and write 0000000000 to hnd=0x23. Switched to handle 0x1a and it worked! I receive many hex-values that should be the data I'm searching for.
So whats the problem?
I want to use gatttool for my purpose or at least I want to understand, why it doesnt worked out with gatttool
When I use bluetoothctl, I just can select and watch one attribute, and after receiving the data, my scale automatically disconnects to my raspberry. So when I select characteristic 0x1a, I cant see the indication-messages of characteristic 0x01d et vice versa.
Is there another connection between my Pi and my Scale when I'm using gatttool or when I'm using bluetoothctl? Or is there a difference in the way, how they communicate to my scale?
The scale appears to be connectable just for a short period of time after the weight etc. has been measured I used the non-interactive mode of gatttool in a bash script like this:
gatttool -t random -b F1:37:57:XX:XX:XX --char-write --handle 0x001f -n 0200
gatttool -t random -b F1:37:57:XX:XX:XX --char-read --handle 0x0021
gatttool -t random -b F1:37:57:XX:XX:XX --char-write --handle 0x001c -n 0200
gatttool -t random -b F1:37:57:XX:XX:XX --char-write --handle 0x0026 -n 0200
gatttool -t random -b F1:37:57:XX:XX:XX --char-write-req --handle 0x0023 -n 0000000000 --listen
Info was taken from Pratik Sinha here.
To get the response displayed the --listen explicitly needed to be given after which some 25 lines of data are received (alternating 1b and 1e responses).
Thanks for your info, saved me days of work!
Happy New Year!
EDIT:
Using Python and the pygatt module this boils down to:
import pygatt.backends
from binascii import hexlify
def printIndication(handle, value):
print('Indication received {} : {}'.format(hex(handle), hexlify(str(value))))
adapter = pygatt.backends.GATTToolBackend()
adapter.start()
# wait for someone to step on the scale
while True:
try:
device = adapter.connect('f1:37:57:xx:xx:xx', 5, 'random')
break
except pygatt.exceptions.NotConnectedError:
print('Waiting...')
device.subscribe('00008a22-0000-1000-8000-00805f9b34fb', callback = printIndication, indication = True)
device.subscribe('00008a21-0000-1000-8000-00805f9b34fb', callback = printIndication, indication = True)
device.subscribe('00008a82-0000-1000-8000-00805f9b34fb', callback = printIndication, indication = True)
try:
device.char_write_handle(0x23, [02,00,00,00,00], True)
except pygatt.exceptions.NotificationTimeout:
pass
device.disconnect()
adapter.stop()
NOTES:
Reading handle 0x21 serves no purpose in my experience
Writing handle 0x23 with 02 followed by the unix timestamp syncs the RTC of the scale
Use the multibyte modified pygatt (pull 34) to be able to receive multiple bytes in an Indication
Although writing to 0x23 will not produce any Notification it is required to wait for a Notification to be able to receive the 0x1b and 0x1e Indications. When the last Indication was received the NotificationTimeout exception is received.
Okay.. I solved this by my self.. all I needed to do was change ,,char-write-cmd" to ,,char-write-req".. In the log-file by my Android-Hci-Snoop it was always a write requst. Don't know why I didn't recognize it all the time...
If someone has the same problem with bluez/bluetoothd/bluetoothctl & dbus like me
(to use the commands "list-attributes", "select" "write" in bluetoothctl you have to execute bluetoothd in Experimental-Mode like "bluetoothd -n -E", but everytime I did this I got some error-messages like "D-Bus: name already in use" or something like "d'bus setup failed: connection is not allowed to own the service due to security..." (don't remember the exact errormessage) )
What I did:
installing bluez with ./configure [...] --enable-experimental (read ReadMe-file)
sudo nano /etc/dbus-1/system.d/bluetooth.conf
--> copied the whole block that starts with >policy user="root">, and paste it below this block. Then I changed "root" to "pi" in one of the two blocks
If someone want to know how this scale provides the measurement results check out this link:
A little Game/Quiz: Do you see my values? (Interpreting Hex-Values)
I now have a Hello World project according this link and I made its .cap
file successfully. I have "DE-ABCM_TB" reader and a SAM card also.
My applet AID is 01 02 03 04 05 06 07 08 09 00 00
I could select my applet on the card.( I sent SELECT APDU command via "DualCard
Ver 2.8"/ pcsc tab) . I now must be receive hello in hex format when I send
8000000000. But i receive 6C0B ! Why did I get this response and
how can I resolve this ? I searched but no solving found.
You didn't searched good enough!
If you do a quick look at status words table you will see SW1=6CXX means Wrong Le field; SW2 encodes the exact number of available data bytes
So you must send the below command:
80|00|00|00|0B!
Table of Status Words :
The dev suggested to ask here to get more help.
This is what is happening, I bought a Raspberry Pi (second one, I know how to handle them, and I'm used to apt and ssh) and a Trendnet TFM561U modem, downloaded NOOBS, did the initial setup with an extra in the shape of Webmin. So far aside from Webmin, it's a vanilla Raspbian. I then downloaded JCblock ( http://sourceforge.net/projects/jcblock/ ) and following the instructions here http://weeklytechforum.com/2013/03/28/block-unwanted-calls-with-a-raspberry-pi/ I edited the files that needed editing and finally compiled. I found out what serial port the modem was using (same as the guide! cool) and finally proceeded to test it. That's where the trouble started.
The differences between me and the guide is that I'm in Italy, so the dev of JCblock made me edit the source with a few extra lines of code to talk to the modem... now it's a great time to point out that while I can edit code and recompile it, this is C and I absolutly have no clue about it, knowing just some basics from Pascal and a bit of Visual Basic, so in the end I'm editing the source blindly, just guessing where things need to go. Anyway the edits are to send the Country Code command: AT+GCI=59\r and Caller ID command: AT+VCID=1\r but we do not seem to be geting caller ID data from the modem.
What I'm expecting to see: I call with my cellphone (and that number is in the blacklist) the Raspberry doesn't make the phone ring, or in case of wrong configuration of the blacklist I get some output that will show a call not filtered.
What I get: the phone rings, the modem data light flashes, the program dosen't output anything.
Any help will be appreciated, thanks.
EDIT:
So, I went ahead and used NCID to see what would happen.
As it generates a cornucopia of data, I think it can be useful
Started: 10/27/2014 22:24:54
Server: ncidd (NCID) 1.0
API: 1.0 Feature Set 1 2 3 4
Command line: ncidd
-Dv3
Logfile: /var/log/ncidd.log
Processed config file: /etc/ncid/ncidd.conf
Verbose level: 3
Configured to send 'cidlog' to clients.
Configured to send 'cidinfo' to clients.
Helper tools:
/usr/bin/cidupdate
/usr/bin/ncidutil
Processed alias file: /etc/ncid/ncidd.alias
Alias Table:
Number of Entries: 1
Leading 1 from a call required in an alias definition
Calls in the blacklist file will be terminated
Processed blacklist file: /etc/ncid/ncidd.blacklist
Blacklist Table:
Number of Entries: 12
Calls in the whitelist file will not be terminated
Processed whitelist file: /etc/ncid/ncidd.whitelist
Whitelist Table:
Number of Entries: 0
CID logfile: /var/log/cidcall.log
CID logfile maximum size: 110000 bytes
Data logfile not present: /var/log/ciddata.log
Maximum number of clients/gateways: 25
Telephone Line Identifier: -
TTY port opened: /dev/ttyACM0
TTY port speed: 19200
TTY lock file: /var/lock/LCK..ttyACM0
TTY port control signals enabled
CallerID from AT Modem and optional gateways
Handles modem calls without Caller ID
Sent Modem 20 of 20 characters:
AT Z S0=0 E1 V1 Q0
Modem response: 26 characters in 1 read:
AT Z S0=0 E1 V1 Q0
OK
Try 1 to init modem: return = 0.
Modem initialized.
Sent Modem 6 of 6 characters:
ATI3
Modem response: 39 characters in 1 read:
ATI3
CX93001-EIS_V0.2002-V92
OK
Sent Modem 9 of 9 characters:
AT+GCI?
Modem response: 27 characters in 1 read:
AT+GCI?
+GCI: 59
OK
Sent Modem 13 of 13 characters:
AT+FCLASS=?
Modem response: 32 characters in 1 read:
AT+FCLASS=?
0,1,1.0,8
OK
Sent Modem 11 of 11 characters:
AT+VCID=1
Modem response: 17 characters in 1 read:
AT+VCID=1
OK
Modem set for CallerID.
Hangup option set to hangup on a blacklisted call
Modem used for CID and to terminate calls
Network Port: 3333
Debug Mode
Not using PID file, there was no '-P' option.
Modem is fd 4
NCID connection socket is sd 5 pos 1
RING
CIDINFO: *LINE*POTS*RING*1*TIME*22:25:21*
CIDINFO: *LINE*POTS*RING*0*TIME*22:25:33*
What I can tell from this, is that it should be properly set up to hang up for a blacklisted number (my cellphone, for testing purposes) and that no caller id gets to the software. About that, it's important to point out how we have a mess of different phones (make, model, cordless, wired...) at home, and all of them do show 1 missed call from me. So at least I can confirm that the caller id is being sent.
I looked on Trendnet TFM561U description page and Amazon for this modem and didn't see "caller ID" in the description.
Your modem looks like it has Caller ID because its response to the activate caller ID command is "OK":
AT+VCID=1
OK
But looking at
Testing Modem Caller ID Support with HyperTerminal (or Putty) page
However, if, in step 8), the modem responded with "OK", then you probably have the correct string. In this case, either your phone line does not have caller id enabled (this can be tested with a hardware caller id device), or the modem does not support caller id. The latter is possible even if, in step 8), the modem responded with "OK", since many modems use the same firmware regardless of whether the modem contains the appropriate caller id hardware. In other words, many modems don't know whether they have caller id support!
I would say return your modem and get one that has "caller ID" in the description.
After selection of the card and RATS, i want to start the authentication.
In the mifare documentation is described that an 0A 00 should be sent. This data is supposed to be ISO14443-4. I have to frame it to fit ISO14443-3.
The Block format goes like that
PCB|CID|INF|EDC
In the PCB I am supposed to say if it is an I-block, R-block or S-block.
I saw an example in this thread where he sent something like that:
90 0A 00 00 01 00 00
Where is it documented this frame, it looks like none of the blocks described in ISO14443-4
The Block format PCB|CID|INF|EDC with I-block, R-block or S-block you described is actually ISO 7816-3 T=1 frame (not ISO 14443 frame, not ISO 7816-4 APDU). This is low-level ISO 7816 that implemented in driver level.
The thread you mentioned uses 7816 APDU.
1st "to card" is actually 7816 APDU: CLA=90 INS=0A P1=00 P2=00 LC=01 Data=00 Le=00
2nd "to card" is another APDU: CLA=90 INS=AF P1=00 P2=00 Lc=10 Data=43 9D 17 8E 9A 5F BA 70 8D 23 57 10 C9 32 D5 17 Le=00.
Depending on the version of Mifare DESFire, you can use native, native-wrapped or ISO 7816-4 command set styles.
7816 wraps Mifare native command as follow:
90 [mifare native ins] 00 00 Lc [data] 00
From the 2 commands above, native commands are 0x0A (Authenticate) & 0xAF (More data).
You can't get the mifare native command set documentation freely. You need to sign an NDA. However, take a look at this doc to see learn more: http://www.nxp.com/documents/application_note/AN11004.pdf
Another resource: http://ridrix.wordpress.com/2009/09/19/mifare-desfire-communication-example/
This is not a ISO 14443 frame; it is an ISO 7816-4 APDU.