ZC23400 iTag

[hcgraf]

Hi,

I got a few iTags which are labeled "ZC23400", this seems to be some kind of a model-identifier. Unfortunately, they don't seem to be working with this app. They can be added, but they start to ring randomly, and ringing from the app gives an error (resource id "something_goes_wrong").

I tried several other apps (iTracing, cTracing) and they also don't seem to work. The only app which seems to work is this JG iTag Alarm.

However, I would very much prefer to use a opensource app, with a lot less permissions…

So, any idea how my tags could be different from those this app is working with? Or any hint how I could help to reverse-engineer the protocol?

Thanks & regards Hagen

[sylvek]

Hi

Your device looks similar to the "itag".. may it possible to use a bluetooth tool app' to discover some useful informations?

this one is my favorite: https://play.google.com/store/apps/details?id=no.nordicsemi.android.mcp

[hcgraf]

Thanks for your feedback! I experimented a bit with about 5 of these devices, and they behave identically, so it's not a single bad device.

1. When I switch it on, it beeps twice and the LED flashes about once every two seconds
2. The phone is able to find it, the name is "ITAG" (all caps)
3. nRF Connect shows an advertising interval of about 100ms, Flags 0x06 and UUIDs Link Loss, Immediate Alert, Tx Power.
4. Bonding does not work, that's probably expected
5. Connecting doesn't work either! And that's probably the problem:
   • Connecting with nRF either shows "disconnected" nearly directly, or it takes several seconds until it (probably) times out.
   • However the ITAG apparently sees that as a successful connection, as it stops blinking
   • After about 30 more seconds, the ITAG starts to beep, probably because the connection is lost.

I guess the JG iTag Alarm app (above) tries to connect more frequently (or doesn't use autoConnect), and thus the iTag doesn't start to beep. It seems that it's also only "apparently working" because it shows some RSSI (maybe just from the advertising messages), button clicks and out-of-range also don't really work…

These tests were made with BQ Aquaris X5 Plus, Stock-Android 6.0.1.

To get some further insight, I also tried it with a Samsung Galaxy S4, Cyanogenmod-Android also 6.0.1. It's suddenly slightly different, as nRF is actually able to connect and discover the services! iTracing2 also seems to work, although it seems a bit unstable after just a few minutes of testing… OK, the hardware it probably quite crappy, I was more or less expecting that ;)

So, any idea what might be the big difference between those two phones? Slightly different BLE revision supported by the hardware?

Regards Hagen

[sylvek]

the bluetooth stack is different for each devices model, the bluetooth chip is not the same.. that the big deal with Android :-/

Regards, Sylvain

Le sam. 11 mars 2017 à 19:26, Hagen Graf notifications@github.com a écrit :

Thanks for your feedback! I experimented a bit with about 5 of these devices, and they behave identically, so it's not a single bad device.

1. When I switch it on, it beeps twice and the LED flashes about once every two seconds
2. The phone is able to find it, the name is "ITAG" (all caps)
3. nRF Connect shows an advertising interval of about 100ms, Flags 0x06 and UUIDs Link Loss, Immediate Alert, Tx Power.
4. Bonding does not work, that's probably expected
5. Connecting doesn't work either! And that's probably the problem:
   • Connecting with nRF either shows "disconnected" nearly directly, or it takes several seconds until it (probably) times out.
   • However the ITAG apparently sees that as a successful connection, as it stops blinking
   • After about 30 more seconds, the ITAG starts to beep, probably because the connection is lost.

I guess the JG iTag Alarm app (above) tries to connect more frequently (or doesn't use autoConnect), and thus the iTag doesn't start to beep. It seems that it's also only "apparently working" because it shows some RSSI (maybe just from the advertising messages), button clicks and out-of-range also don't really work…

These tests were made with BQ Aquaris X5 Plus, Stock-Android 6.0.1.

To get some further insight, I also tried it with a Samsung Galaxy S4, Cyanogenmod-Android also 6.0.1. It's suddenly slightly different, as nRF is actually able to connect and discover the services! iTracing2 also seems to work, although it seems a bit unstable after just a few minutes of testing… OK, the hardware it probably quite crappy, I was more or less expecting that ;)

So, any idea what might be the big difference between those two phones? Slightly different BLE revision supported by the hardware?

Regards Hagen

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/sylvek/itracing2/issues/96#issuecomment-285889823, or mute the thread https://github.com/notifications/unsubscribe-auth/ACJ4nbMw0yhy7rvJW7MzEBE8uPlkTlimks5rkuc9gaJpZM4MZ1KG .

[dwaynez]

I also have an itag and have successfully connected with itracing2 (eventually).. I am still doing some experimenting, but here is what I am thinking:

1. First connect works just fine.
2. If the tag disconnects from itracing2, I get the forever spinning wheel. To get arount this I either need to reconnect with the native app for itag, called isearching first or I think if I check off the tag in itracing2 and then recheck it, it seems to connect just fine. I have downloaded the code and still need to do some testing, but I think there needs to be some addition things done on disconnect to force a connectGatt on the next connect attempt.

[sylvek]

Hi, I'm pretty sure that works.. But when a disconnection occurs, the reconnection is managed by Android and the bluetooth stack himself and not by itracing2. This reconnection takes time indeed, but what works with my own devices. If you have time, we could do more tests.

Regards