Baffled by Bluetooth - Help
Posted: Sun Jul 11, 2021 6:23 pm
I thought I had at least a basic understanding of how Bluetooth LE works, but it appears not.
I'm trying to get an ESP32 TTGO T-display (acting as a central) reading output from an OBDII reader. The OBDII reader advertises a single characteristic with READ, WRITE and NOTIFY properties and, as far as I can tell, most but not all, output is via WRITE and READ.
I'm using @jimmo's ble_simplecentral.py as my starting point and have added _IRQ_GATTC_READ_RESULT and _IRQ_GATTC_READ_DONE to the _irq method. After initialising the OBDII reader the main loop of my program then iterates around first sending a ble.gattc.write (central.write) to the peripheral and then a ble.gattc_read (central.read) to read (I thought) the output from the reader either through a read callback or notify callback.
However, it is not working as planned. The relevant part of my code is:and the responses I'm getting back are:once the 220101/220105/2102 cmd is written/sent I should get back a stream of data of approximately 200 bytes. I am not getting anything back as far as I can see although, on a couple of occasions I may have got the first few bytes of a proper return so this may just be down to a timing issue.
However, I had thought that once I had issued a write cmd (which, in my mind, should cause the peripheral to place the required data in the output buffer ready to be pulled up by the subsequent read or notify cmd) I should get the expected data when the _IRQ_GATTC_READ_RESULT irq is detected.
Why am I getting the previous write cmd (not even the current one) and only the first character of it in the read callback and the current write cmd in the notify callback. It is as if there is some sort of queued data waiting to be pulled and I'm slow (or too fast) trying to read it.
Help, someone!
I'm trying to get an ESP32 TTGO T-display (acting as a central) reading output from an OBDII reader. The OBDII reader advertises a single characteristic with READ, WRITE and NOTIFY properties and, as far as I can tell, most but not all, output is via WRITE and READ.
I'm using @jimmo's ble_simplecentral.py as my starting point and have added _IRQ_GATTC_READ_RESULT and _IRQ_GATTC_READ_DONE to the _irq method. After initialising the OBDII reader the main loop of my program then iterates around first sending a ble.gattc.write (central.write) to the peripheral and then a ble.gattc_read (central.read) to read (I thought) the output from the reader either through a read callback or notify callback.
However, it is not working as planned. The relevant part of my code is:
Code: Select all
def on_rec(v):
print("< rec - ",str(v,"utf-8"))
def on_rx(v):
# return
print("< not - ",str(v,"utf-8"))
central.on_notify(on_rx)
with_response = False
while central.is_connected():
cmds = ["ATSH7E4","220101","ATSH7E4","220105","ATSH7E2","2102"]
for cmd in cmds:
try:
v = cmd+"\n"
print("> write - ", v)
central.write(v, with_response)
time.sleep(2)
print("< loop - ",str(central.value(),"utf-8"))
except:
print("TX failed on - ", cmd)
time.sleep_ms(2000 if with_response else 2000)
central.read(callback=on_rec)
print("Disconnected")
Code: Select all
> write - ATSH7E4
< data1 = 2 <----- print("< data1 = ",str(char_data,"utf-8")) called immediately after _IRQ_GATTC_READ_RESULT:
< rec - 2 <----- read callback (note, this is the first character of the previous write cmd [220101])
< not - ATSH7E4 <----- notify callback (this is the current write cmd)
< loop - ATSH7E4 <-----this is the central.value value from after the write cmd
> write - 220105
< data1 = A
< rec - A
< not - 220105
< loop - 220105
However, I had thought that once I had issued a write cmd (which, in my mind, should cause the peripheral to place the required data in the output buffer ready to be pulled up by the subsequent read or notify cmd) I should get the expected data when the _IRQ_GATTC_READ_RESULT irq is detected.
Why am I getting the previous write cmd (not even the current one) and only the first character of it in the read callback and the current write cmd in the notify callback. It is as if there is some sort of queued data waiting to be pulled and I'm slow (or too fast) trying to read it.
Help, someone!