I’ve confirmed that data from an external Bluetooth device can be forwarded to my server (this direction works fine).
Now I’m trying to understand whether there is also a reverse channel:
Can the server send data back through the FMC003 to the paired Bluetooth device?
On some Teltonika devices I found documentation mentioning CMD ID / Type = 0x0E or 0x10 for forwarding to external devices (e.g. RS232 / Bluetooth forwarding). However, on the FMC003 I can’t get this working:
In debug logs, the commands seem to be recognized, but there is no effect on the external device.
0x0E returns something like “RS232 not configured” (makes sense since FMC003 has no Hardware RS232).
0x10 doesn’t seem to provide the “forward to paired Bluetooth device” function on this model.
So my question is:
Is there any supported way on FMC003 to send arbitrary data/commands from the server back to a paired Bluetooth device?
I’ve seen some posts in this community suggesting that the answer might be yes.
If yes, which codec/command type should be used (Codec12/13/14?), and are there any required configuration steps?
Indeed as you mentioned, it’s possible to send commands from you Server back to the Bluetooth device that’s paired with the FMC003.
Please ensure that Data Link is configured in Blutooth Tab > Auto Connect to External Device, and Bluetooth is Enabled.
Also, the command that needs to be fowarded to the External Bluetooth device needs to be encapsulated in a Codec 12 message format, then sent to the Teltonika tracker over GPRS when the Data Link (GPRS Session) between the FMC003 and Server is Open.
Make sure that Codec 12 protocol is implemented on your Server. You can learn more about this protocol by clicking on the link below:
For example, let’s say you need to send the following command to the External Bluetooth device to control a certain fonctionality: #FWD DAT= 3,1,A00101A2
#FWD DAT= 3,1,A00101A2 => Covert it from ASCII to Hex =>
0x 23 46 57 44 20 44 41 54 3D 20 33 2C 31 2C 41 30 30 31 30 31 41 32 => Encapsulate it in a Codec 12 message format => 0x 00 00 00 00 00 00 00 1E 0C 01 05 00 00 00 16 23 46 57 44 20 44 41 54 3D 20 33 2C 31 2C 41 30 30 31 30 31 41 32 01 00 00 14 0C => Send this command to the FMC003 from your Server when the Data Link (GPRS Session) is Open
thanks for your message — that was the breakthrough. I did know that I have to wrap it using Codec12, but I’m still missing one key part: where is the #FWD command documented?
When I search for it, I can only find hints in the firmware/debug logs, but no official documentation page describing the syntax and parameters.
Regarding the example:
#FWD DAT= 3,1,A00101A2
The first parameter seems to indicate the interface. From what I can tell: 1/2/3 = RS485 / RS232 / Bluetooth (or similar mapping depending on model). Is that correct for the FMC003?
What exactly does the second parameter represent?
And for the payload: A00101A2 looks like raw hex bytes. Is there a way (a parameter/format change) to send an ASCII string directly, or do I always need to convert the string to hex bytes before sending?
Hi again,
I think i get it. The second parameter is 0 for text data, 1 for binary.
What is de maximum datasize ?
But the big question is open, where is this documented
#FWD DAT=x,y,data — For example: #FWD DAT=3,1,A00101A2
x (Destination): x=3 is for devices that support BT3 (such as the FMC003) when paired with an external Bluetooth device via Data Link Mode only.
y (Format): y=0 for ASCII String and y=1 for HEX String.
Workflow:
Construct your command => Convert it from ASCII to Hex => Encapsulate it in a Codec 12 message format => Send it to the FMC003 from your Server while the Data Link (GPRS Session) is OPEN.
You should expect a response from the tracker after sending the Codec 12 message. The reply is also encapsulated in a Codec 12 response format.
Important Notes:
Regarding Data Size, in general, a Codec 12 message packet should not exceed 1000 bytes. Please ensure that when you encapsulate the #FWD DAT=x,y,data command, the entire packet remains within this length limit.
For the Documentation, this command is not publicly documented, so you will not find it on Teltonika Wiki.
Got it — seems this is one of those internal “secret” functions . It works perfectly in my case.
I still have one question regarding FMC003 with NBL-2:
Is the firmware fully compatible with NBL-2?
I have emulated the NBL-2 advertising packet. I can see it in the NblTools app on Android, so it is okey. Also when I define the reader as an Advanced Sensor and set Type FF / DataSize 20, the data is displayed correctly in the configurator.
However, when I configure the reader as an NBL-1 Reader, the ID in the I/O list always remains 0x00000000.
So as configured as Sensor => ADV Packet accepted by Tracker
As Reader => not detected
Is this a known behavior / limitation of the current firmware, or is there a recommended configuration for this use case?
BTW I also tried Type 16 as in your documentation, but i think its not correct. Firmware and Manual from Netronix says ADV uses 0xFF
Happy to hear that the command works perfectly on your side.
Regarding the NBL-2, we would like to analyse this issue in more detail, therefore please contact your Teltonika Sales Manager.
If you don’t have any contacts with our Sale Managers, please contact with them on our official website https://teltonika-gps.com/ and click on the “Contact Us” button. When you will click, please fill the form and submit it.
I spent some more time investigating the issue on my side.
According to both the Teltonika and Nextronix documentation, the service data should be 21 bytes long:
1 byte length
1 byte type
19 bytes data
What I found is that the parser seems to search for the UUID "NX" and then performs a length check for 18 bytes only. In other words, the parser appears to enforce an 18-byte limit, even though 19 bytes should still be accepted according to the documentation.
If I follow the documentation exactly, the tracker does not recognize the ADV packet. However, the original NblTool app reports everything correctly. After shortening my emulated packet by 1Byte, it works immediately.
Interestingly, after this change, the NblTool app reports the device as NBL-4 instead of NBL-2.
Observed behavior
A value/token with 18 characters is accepted.
The same field with 19 characters is rejected, truncated, or fails validation.
Here my 0xFF hexcode with the original 19Byte length
Thank you for the time and effort spent investigating this issue.
We would like to analyze this issue in more detail and provide a fix. Please contact your Teltonika Sales Manager to proceed.
If you don’t have any contacts with our Sale Managers, please contact with them on our official website https://teltonika-gps.com/ and click on the “Contact Us” button. When you will click, please fill the form and submit it.
I do not have a dedicated sales contact, as my device was purchased for evaluation purposes. Unfortunately, my previous email contact with sales was not very helpful, as the focus was strongly on making a sale rather than answering my questions.
That is why I really appreciate the community support. I’m happy to help if there are any questions, and I think it’s great to see how committed Teltonika is here.
Hi Gunther, how are you?I’m working on an application where I need to send data to my server.How did you manage to send data from the external Bluetooth device to your server?
That was actually the easy part. The tracker is in datalink mode. The device sends the strings it wants to send, and they end up on the server. What exactly is your problem?
I’m developing an app that will need to be connected to Teltonika via Bluetooth and will send data through it to the server, which will be used to identify the person.
Through the app, it will also be possible to lock and unlock the vehicle.
I can already lock and unlock the vehicle.
But I can’t send data through Teltonika to the server.
DataLink mode is required for communication between the end device and the server. In this scenario, the end device acts as the host, and the tracker actively connects to the end device. Note that the MAC address or part of the Bluetooth name must be known. The connection is then “transparent” between the end device and the server. During this time, you cannot read data from the tracker.
Either you use a Bluetooth LE connection in parallel, or you communicate with the server, which then sends the lock/unlock commands to the tracker. The round trip takes a little longer.
Why do you want to communicate with the tracker via the Bluetooth app? You already have internet on your smartphone. The connection is faster and more reliable.
. It works perfectly in my case.