Android Question Bluetooth 4.0 data exchange

red30

Well-Known Member
Licensed User
Longtime User
I have a microcontroller to which the Bluetooth HC-08 (Bluetooth 4.0) module is connected. I want to exchange data, but I have not found a single example on the forum. I need to work exactly with Bluetooth 4.0. How can i do this?
I found the program Serial Bluetooth Terminal. Can I do the same with b4a?

I tried this example. I get the error: java.io.IOException: read failed, socket might closed or timeout, read ret: -1

I found the program from the official manufacturer, it works fine with this bluetooth module.
 

Attachments

  • 2016330162415101 (1).zip
    329.7 KB · Views: 639
Last edited:

red30

Well-Known Member
Licensed User
Longtime User
Thank you very much for the information.
In the video, I noticed that the Serial Bluetooth Terminal program was also open on the phone. I downloaded it and it works great with this module.
I do not understand why nRF Connect reads the value of a variable, but B4A does not ... Why is this happening?
I will try other options, I will report the results!

Here is the documentation for the bluetooth module. Suddenly it will be useful ...

Also in the first post I posted the application from the manufacturer of this Bluetooth module. If it were possible to somehow transform from the apk into the code to see how the manufacturer implemented it?
 
Last edited:
Upvote 0

f0raster0

Well-Known Member
Licensed User
Longtime User
When I use program BLE_Example, when I press button Read Data, I get this:
View attachment 77760
View attachment 77761
View attachment 77762
Can someone explain how to transfer and receive data from the Bluetooth module? I could not find more than one topic where it was explained. Sorry if I do not understand something ...
I use the modules nRF BLE to read data we have to send "nofity true" maybe that is your case you need to active it.

Have a look to this example
https://www.b4x.com/android/forum/threads/ble-receiving-send-problem.102026/#post-640771

Question, you can not read data using B4x app? Or the problem now is sending data to the module?
 
Upvote 0

red30

Well-Known Member
Licensed User
Longtime User
Question, you can not read data using B4x app? Or the problem now is sending data to the module?
I can not receive data, do not send data to the bluetooth module with the help of B4x. I gave above that with the help of the application nRF Connect I can send and receive data (they are in "0000ffe1-0000-1000-8000-00805f9b34fb"),
Screenshot_20190228-101910.png
but when I watch "0000ffe1-0000-1000-8000-00805f9b34fb" (at B4x) there is nothing there ...
 
Upvote 0

emexes

Expert
Licensed User
1/ Change this bit of the DataAvailable routine to:

B4X:
                If C.StartsWith(CharacteristicIdStartsWith) Then    'and this one is it
                    SaveCharacteristicId = C    'then save it (ServiceId already saved)
                   
                    'if SetIndication doesn't work, then try SetNotify
                    Dim Result As Boolean = BleMan.SetIndication(SaveServiceId, SaveCharacteristicId, True)
                    Log("SetIndication " & Result)
                   
                    'BleReadTimer.Interval = 10000    'and read it every 10 seconds
                    'BleReadTimer.Enabled = True
                End If

ie add 3 x SetIndication lines and comment out 2 x timer lines

2/ Give it a go, and send at least 100 characters from your terminal program, in say various chunks of 10..30 characters

My results are below, except
(i) my readings are 16 bit signed integers, you should be getting ASCII characters (possibly in chunks of 20)
(ii) my UUIDs are different, you should be using that prime suspect characteristic 0000ffe1, and
(iii) this #@%! pressure sensor doesn't do indications, only notifications, but the main aim is confirmed: every time the pressure reading changes, the sensor sends the new data via BLE to the B4A app where it generates a DataAvailable event.

B4X:
*** Service (starter) Create ***
Let the games begin...
** Service (starter) Start **
** Activity (main) Create, isFirst = true **
** Activity (main) Resume **
Device = 78:59:88:95:CD:16  -33
Device = FF:FF:C0:20:9A:E5 iTAG -33
Device = 47:00:33:6D:1F:AE  -25
Device = 60:03:08:B9:B3:AA  -33
Device = 07:42:08:E3:ED:4A  -46
Device = 3A:43:0C:CD:15:81  -46
Device = C8:69:CD:10:1E:C9  -33
Device = D3:CC:CB:F7:AC:09 34507 -27
Discovering services.
Connected
Service = 00001800-0000-1000-8000-00805f9b34fb
Service = 00001801-0000-1000-8000-00805f9b34fb
Service = cc4a6a80-51e0-11e3-b451-0002a5d5c51b
Service = 0000180f-0000-1000-8000-00805f9b34fb
Service = 00001804-0000-1000-8000-00805f9b34fb
Service = 0000180a-0000-1000-8000-00805f9b34fb
Service = 000018ff-0000-1000-8000-00805f9b34fb
DataAvailable cc4a6a80-51e0-11e3-b451-0002a5d5c51b
Characteristic 835ab4c0-51e4-11e3-a5bd-0002a5d5c51b = ".." FF E2
Setting descriptor. Success = true
writing descriptor: true
SetNotify true
Characteristic 8cd67da0-da9b-11e3-9087-0002a5d5c51b = "." 01
Characteristic 00002a1c-0000-1000-8000-00805f9b34fb = ".A..." 00 41 BD 00 00
Characteristic 00002a21-0000-1000-8000-00805f9b34fb = ".." 1E 00
DataAvailable cc4a6a80-51e0-11e3-b451-0002a5d5c51b
Characteristic 835ab4c0-51e4-11e3-a5bd-0002a5d5c51b = ".." FF E1
DataAvailable cc4a6a80-51e0-11e3-b451-0002a5d5c51b
Characteristic 835ab4c0-51e4-11e3-a5bd-0002a5d5c51b = ".." FF E2
DataAvailable cc4a6a80-51e0-11e3-b451-0002a5d5c51b
Characteristic 835ab4c0-51e4-11e3-a5bd-0002a5d5c51b = ".." FF E2
DataAvailable cc4a6a80-51e0-11e3-b451-0002a5d5c51b
Characteristic 835ab4c0-51e4-11e3-a5bd-0002a5d5c51b = ".." FF E1
DataAvailable cc4a6a80-51e0-11e3-b451-0002a5d5c51b
Characteristic 835ab4c0-51e4-11e3-a5bd-0002a5d5c51b = ".." FF E2
DataAvailable cc4a6a80-51e0-11e3-b451-0002a5d5c51b
Characteristic 835ab4c0-51e4-11e3-a5bd-0002a5d5c51b = ".." FF E7
DataAvailable cc4a6a80-51e0-11e3-b451-0002a5d5c51b
Characteristic 835ab4c0-51e4-11e3-a5bd-0002a5d5c51b = ".." FF E8
DataAvailable cc4a6a80-51e0-11e3-b451-0002a5d5c51b
Characteristic 835ab4c0-51e4-11e3-a5bd-0002a5d5c51b = ".." FF E6
DataAvailable cc4a6a80-51e0-11e3-b451-0002a5d5c51b
Characteristic 835ab4c0-51e4-11e3-a5bd-0002a5d5c51b = ".." FF EE
DataAvailable cc4a6a80-51e0-11e3-b451-0002a5d5c51b
Characteristic 835ab4c0-51e4-11e3-a5bd-0002a5d5c51b = ".." FF EA
DataAvailable cc4a6a80-51e0-11e3-b451-0002a5d5c51b
Characteristic 835ab4c0-51e4-11e3-a5bd-0002a5d5c51b = ".." FF E8
 
Upvote 0

emexes

Expert
Licensed User
Oh, yeah, and I added these two routines and changed the relevant Log call...

B4X:
'*** AND LAST, BUT BY NO MEANS LEAST, A FUNCTION TO STOP ME GOING CROSS-EYED ***

Sub ByteArrayToReadableString(BA() As Byte) As String
 
    Dim ReadableAscii As String = ByteArrayToAsciiString(BA)
    Dim ReadableHex As String = ByteArrayToSpaceSeparatedHexString(BA)

    Return Chr(34) & ReadableAscii & Chr(34) & " " & ReadableHex
   
End Sub

Sub ByteArrayToAsciiString(BA() As Byte) As String
 
    Dim AsciiString As String = ""
    Dim Ch As byte
 
    For I = 0 To BA.Length - 1
        Ch = BA(I)
   
        If Ch >= 32 And Ch <= 126 Then    'within byte range so no sign problem
            AsciiString = AsciiString & Chr(Ch)
        Else
            AsciiString = AsciiString & "."
        End If
    Next
 
    Return AsciiString
 
End Sub

Sub ByteArrayToSpaceSeparatedHexString(BA() As Byte) As String
 
Upvote 0

f0raster0

Well-Known Member
Licensed User
Longtime User
I can not receive data, ......
but when I watch "0000ffe1-0000-1000-8000-00805f9b34fb" (at B4x) there is nothing there ...
the nRF connect is a super cool great App dedicated for Bluetooth, I use it with my modules too.

did you try this example:
https://www.b4x.com/android/forum/threads/ble-receiving-send-problem.102026/#post-6407
there was needed SetNotify = true, maybe it is your case
have a look the example and post the code and longs.. maybe we can find the solution..
 
Upvote 0

red30

Well-Known Member
Licensed User
Longtime User
1/ Change this bit of the DataAvailable routine to:

Code:
If C.StartsWith(CharacteristicIdStartsWith) Then 'and this one is it
SaveCharacteristicId = C 'then save it (ServiceId already saved)

'if SetIndication doesn't work, then try SetNotify
Dim Result As Boolean = BleMan.SetIndication(SaveServiceId, SaveCharacteristicId, True)
Log("SetIndication " & Result)

'BleReadTimer.Interval = 10000 'and read it every 10 seconds
'BleReadTimer.Enabled = True
End If
ie add 3 x SetIndication lines and comment out 2 x timer lines
I did it and everything works fine !!! The data comes exactly the ones I sent! If the data is> 20 bytes, it breaks it into two messages.

*** Service (starter) Create ***
Let the games begin...
** Service (starter) Start **
** Activity (main) Create, isFirst = true **
** Activity (main) Resume **
Device = 20:C3:8F:FD:68:52 HC-08-TEST -22
Discovering services.
Connected
Service = 00001800-0000-1000-8000-00805f9b34fb
Service = 00001801-0000-1000-8000-00805f9b34fb
Service = 0000180a-0000-1000-8000-00805f9b34fb
Service = 0000fff0-0000-1000-8000-00805f9b34fb
Service = 0000ffe0-0000-1000-8000-00805f9b34fb
DataAvailable
Setting descriptor. Success = true
writing descriptor: true
SetIndication true
DataAvailable
Characteristic 0000ffe1-0000-1000-8000-00805f9b34fb = 74 65 73 74 20 64 61 74 61
DataAvailable
Characteristic 0000ffe1-0000-1000-8000-00805f9b34fb = 74 65 73 74 20 64 61 74 61
DataAvailable
Characteristic 0000ffe1-0000-1000-8000-00805f9b34fb = 31 32 33
DataAvailable
Characteristic 0000ffe1-0000-1000-8000-00805f9b34fb = 30 30 30
DataAvailable
Characteristic 0000ffe1-0000-1000-8000-00805f9b34fb = 31 32 33 34 35 36 37 38 39
DataAvailable
Characteristic 0000ffe1-0000-1000-8000-00805f9b34fb = 31 32 33 34 35 36 37 38 39 30
DataAvailable
Characteristic 0000ffe1-0000-1000-8000-00805f9b34fb = 31 32 33 34 35 36 37 38 39 30 30 30
DataAvailable
Characteristic 0000ffe1-0000-1000-8000-00805f9b34fb = 31 32 33 34 35 36 37 38 39 30 30 30 30 30 30 30 30 30 30 30
DataAvailable
Characteristic 0000ffe1-0000-1000-8000-00805f9b34fb = 30 30 30 30 30 30
** Activity (main) Pause, UserClosed = false **

Thank you very much!!! Now I can accept the data, it remains only to understand how to send them ...
 
Upvote 0

emexes

Expert
Licensed User
I did it and everything works fine !!! The data comes exactly the ones I sent! If the data is > 20 bytes, it breaks it into two messages.

Mate, am I happy to hear that good news !!!! Who'd have thought that one single bit could make such a difference ?!

Sending the data should be just a case of using WriteData to the same 0000ffe1 characteristic, and pacing yourself by waiting for the WriteComplete event (or a reasonable timeout) before doing the next WriteData, as per:

https://www.b4x.com/android/help/ble2.html

I saw somewhere something about 20-byte blocks, so probably best stick to sending in chunks of that size or less as well. Although you could try larger chunks, see how it goes, but... I don't know about you, but I've got enough problems to keep me entertained as it is, without needing to lay extra landmines in my future as well.

The reason that the receiving data needs indications would be that: normal Bluetooth reads are not confirmed, in that there is no confirmation that the data has been received by the B4A app, ie, the packet might have been corrupted by noise or a transmission clash. For normal use cases, this'd be no problem, because either (i) if we desperately need that data, we'd just do another ReadData when we didn't hear back from the first one, and (ii) when we get the next data update (whether by notification or ReadData request) then the missed data is no longer valid or necessary, because we've got a replacement for it.

But when that data is a stream of bytes, then missing or duplicated data becomes a drama. BLE notifications send data when it changes, but without confirmation. BLE indications send data when it changes, and keep at it until it gets confirmation that that data has been received.

Adios, Amigo!
 
Upvote 0

red30

Well-Known Member
Licensed User
Longtime User
Thank you again for your help!
I couldn't have done it without you!
Now I will write the data transfer and post the code here so that it will help someone else!
 
Upvote 0

red30

Well-Known Member
Licensed User
Longtime User
As promised, here is a program that can read and write data through the Bluetooth module HC-08. Maybe it looks a bit unfinished, but it works, you can still improve it.
Thanks again for the help!
Maybe I will have questions ...I will write them here.
 

Attachments

  • BLE HC-08.zip
    10.9 KB · Views: 409
Upvote 0

red30

Well-Known Member
Licensed User
Longtime User
Another such question appeared: there is such a parameter RSSI (as I understood it so I can indirectly determine the distance to the device). Can I somehow request this option except "Sub BleMan_DeviceFound (Name As String, Id As String, AdvertisingData As Map, RSSI As Double)"?
 
Upvote 0

emexes

Expert
Licensed User
Another such question appeared: there is such a parameter RSSI (as I understood it so I can indirectly determine the distance to the device). Can I somehow request this option except "Sub BleMan_DeviceFound (Name As String, Id As String, AdvertisingData As Map, RSSI As Double)"?

Request RSSI usng ReadRemoteRSSI, then some short time later you get RssiAvailable (Success As Boolean, RSSI As Double) of the device you are connected to.

https://www.b4x.com/android/help/ble2.html#blemanager2_readremoterssi

My understanding is that, when you are connected to a BLE device, there are keep-alive/synchronization packets being regularly exchanged between the two devices, and that the RSSI level is the level measured at the Android device of the (not sure which) most-recent or next-received packet from the BLE device.

This level will often be higher than the RSSI at DeviceFound time, since that packet was an advertisement, and devices that work off batteries like to transmit advertisements at the lowest power level they can get away with, in order to maximize battery life.

My experiments at a show last week confirmed that distance measurement is more of a (lots of handwaving) close-medium-far indication, with "accuracy" around -50%-+100%. And each Android device returns different readings for the same remote device, and of course the remote devices will be transmitting at different power levels, depending on their energy constraints. And in the case of the show, I had (i) people passing through the line-of-sight between the BLE devices (depending on where I stood), and (ii) typically 80-100 advertisers within range at any one time (including cash registers, EFTPOS terminals, televisions, key tags, fridges...)

There was plenty of wifi about as well, which shares the same radio spectrum. And not all devices advertise. I did wonder also if I might be missing ads whilst my code was busy adding to lists and doing screen updates.

If you set the last parameter of Scan2, then you'll see all the advertisements that are flying around. Apple devices usually emit 10 ads per second, most devices emit 1 or 2 per second, and the pressure sensor I have here with a battery life of "up to 2 years" emits an ad every 2 seconds. The iTags I have advertise 1 per second, but if you press their button, then *some* of them emit a 2-second flurry of advertisements at about 10 per second, which I assume include the button state.

Which reminds me: I was going to investigate what was going on with the advertising data, and ReadData2 returning multiple readings...
 
Last edited:
Upvote 0

emexes

Expert
Licensed User
red30 said:
I also noticed on Friday that if I make a request for BleMan.WriteData, and I do not ask again, there are times that it does not reach at all ... Why can this happen?

Are you into fishing? You sure do like opening cans of worms :)

I expect what's happening is that a BLE write is not guaranteed, as in the Android BLE interface isn't automatically retrying failed operations that got clobbered by competing wifi or other Bluetooth transmissions (or you reheating your coffee in the microwave...) The write request is sent out, and if the BLE device happens to hear it, then it sends back a "no worries, got that, thanks" message that also might separately get clobbered and never make it back to you as a WriteComplete event.

Now, for normal BLE GATT operation, this isn't so bad. Let's say we want to set a BLE-controlled light to 40% on, we do a WriteData 40 to the light-level characteristic, the light receives it, sets the light accordingly, sends us back a confirmation which we receive as a WriteComplete event, and we'e like: job done; how easy was that?

At least that's how it works according to the spec sheet and in the classroom. In the real world and the 2.4 GHz radio band, it's more like:


dragons.jpg


But for our 40% light example, we're ok: if we don't get that WriteComplete confirmation back within a reasonable time, we just try again, until nature submits to our persistence (and laws of probability) and we fluke both the outgoing and return transmissions making it across that radio ocean unscathed.

Sometimes our outgoing packet might get through ok, but the return confirmation is lost, and thus we repeat the outgoing packet and that gets through too (ie, received twice). No harm done in our 40% light example - the light still ends up at the write setting ie 40%. Duplication is no problem, to be sure, to be sure.

But now, what about this HM-10/HC-08 serial link? We send (say) 50 bytes of data, it gets broken down into 20:20:10 byte chunks and sent as 3 writes over BLE. Assuming them dragons be looking the other way and those 3 packets all get through ok, everything's great - the HM-10/HC-08 module receives the 20+20+10 bytes, shoves 'em out the serial port, we get our WriteComplete confirmations, life is sweet. Ship that baby!

But if one of those packets goes missing, what do we do? We know something's gone wrong, in that we're missing a WriteComplete confirmation, but we don't know precisely what has gone wrong, in that it could be one of these two scenarios:

(1) the outgoing message got clobbered, and thus no confirmation was sent
(2) the outgoing message got through, but the return confirmation got clobbered

It all looks the same to us, ie, we didn't get confirmation that the data got through. Our two options are:

- repeat the write request, which solves for scenario 1, but results in data double-up if it was scenario 2, eg: we send "one two three four five six seven eight nine ten" but what comes out the UART at the other end is "one two three four five six seven eight ive six seven eight nine ten". Nice try, but no cigar.
- ignore the issue, which solves for scenario 2, but results in data loss for scenario 1, eg "one two three four f{lost data}nine ten". This is definitely a no-cigar result.

Many protocols solve this problem by sequence-numbering individual packets, but I'm pretty sure BLE doesn't do this*. And, as with the 40% light example above, this is no problem for the usual BLE use-case. Presumably the reasoning behind leaving it out was that: if somebody needs it, they can do it themselves.

{*I could be wrong here, maybe BLE does do this - and it'd be fantastic if it did - but I haven't seen anything that confirms it}

So, some applications using HM-10/HC-08 modules as a serial link replacement could be headed straight for that dragon zone.

In your case, though, given that you can align your outgoing serial data packets on, and within, the 20-byte packetization by the HM-10/HC-08 module, you should be ok.

It is possible that the return data might be split across two packets, eg 3 bytes in one packet and 5 bytes in the next, but because you're only expecting return 8-byte packets in-between requests, this should also be ok, provided that you're using BLE indications (ie, confirmed) rather than notifications (ie, unconfirmed).

If you don't get a WriteComplete for an 8-byte request that you've sent, then you just send it again, and (as I understand it) if your PIC happens to get both 8-byte requests, then it will either reply once (no problem) or twice (still mostly* no problem, because both 8-byte responses will fit within a single 20-byte return BLE packet).

{*ok, ok, yes... it is possible that they might be split across two packets, but I'm pretty sure that will be taken care of anyway because you're already awake to the possibility that even a single 8-byte response might be split across two BLE packets and, worst case, if the duplicate responses were split at the 8-byte response boundary and thus you weren't expecting the second one because you've already received the first one without anything extra (yet), then - as I understand it - you can identify responses by their header bytes, so: what could possibly go wrong?!?!)
 
Last edited:
Upvote 0

emexes

Expert
Licensed User
I expect you've already got experiments galore planned for Monday, so this could sound like teaching you to suck eggs, but... you never know, perhaps there might be a gem in here somewhere:

- send your 8-byte requests at one byte every 2.5 HM-10/HC-08 BLE periods (20 ms?) ie one byte per 50 ms.

What I would expect you'd see on the serial lines with your 'scope is: the eight request bytes on the UART output, with bytes separated either 20 ms and 40 ms apart, ie, aligned with the 20 ms period, and then the 8 byte response in a single burst on the UART input, which then gets sent back to the Android device on (usually) one or (sometimes) two BLE packets and received in B4A via DataAvailable events.

It'd be interesting to timestamp the B4A WriteData requests and DataAvailable responses in the log, to get an idea of:
- how long the return trip takes,
- do the responses ever get split (depending on the turnaround time at the PIC end, perhaps not)
- are split responses received 20 ms apart or can multiple packets be sent at each 20 ms point?
- are WriteData's done immediately, or (more likely) held until the next 20 ms period
- what happens if multiple WriteData's totalling < 20 bytes are done within a single 20 ms interval?
- what happens if multiple WriteData's totalling > 20 bytes are done within a single 20 ms interval?

- then change the one byte per 2.5 periods to one byte per 1.5 periods ie 30 ms, when I'd expect you'd see the bytes come out the uart spaced mostly 20 and sometimes 40 ms apart

- then change to one byte per 1.2 periods ie 24 ms, when I'd expect you'd see the bytes come out the uarts spaced 4 of them 20 ms apart and then one 40 ms apart

- then change to one byte per 0.8 periods ie 16 ms, when I'd expect you'd see something at every 20 ms point, including an occasional 2-byte burst

- then change to one byte per 0.4 periods ie 8 ms, when I'd expect you'd see 2 bytes pop out at every 20 ms point, with frequent 3-byte bursts (alternating 2-3-2-3...?)

- then do those tests again but send the requests as two-byte chunks instead of single bytes

and at the end of all that you'll probably be the world's most knowledgeable expert on the quirks of using these modules as a serial line replacement...

;-)
 
Upvote 0

emexes

Expert
Licensed User
During our adventure, I don't think we've ever put our various HM-10/HC-08 serial link deductions and discoveries in one place, so:

My mental picture of how it works is...

- there is a regular communication window between the module and the Android device, every 20 ms. Presumably the module is asleep for most of that time, to minimize energy use (and the module's UART is in a low-power mode that can handle the "occasional" incoming UART byte coming in eg every 86,000 ns @ 115200 baud).

- when you do a WriteData on the Android side, that data waits until the next 20 ms communication window, at which point the module BLE wakes up and turns on the radio for news, receives the bytes sent shortly thereafter by the Android device and hands them over to the UART*, sends back a WriteComplete confirmation, then goes back to sleep

- when you send data in the opposite direction, into the HM-10/HC-08 UART, then that data is put in a buffer, and when the next 20 ms communication window opens up, the next up-to-20 bytes from that buffer is sent to the Android device

{* I'm guessing the UART has a large-enough buffer to be able to handle say 16 bytes of incoming and outgoing data whilst the CPU is asleep, and that it can wake up the CPU if it needs attention... or the CPU just wakes up anyway for say 1000 ns every 1000000 ns to check how things are going = 0.001 power duty-cycle}

and my (current) remaining wonderings are:

- does BLE send just one up-to-20-byte packet each communication window, in each direction, or can it send several?

- can BLE do both directions in one communication window, or only one direction?

- if one direction: does it alternate direction at each communication window, or does one direction always take priority over the other?

- if both directions: which direction is done first? (probably of minor consequence, given that there's almost no way we'd be able to generate a return packet during the turn-around period)

I expect the Android-to-module direction is done first, because it's the module end that likely has the battery life low energy constraints, and so we want to avoid tx as much as possible (ie, only tx when absolutely necessary, like if there is data to send back, or a keep-alive flag-waving is due).
 
Last edited:
Upvote 0

udg

Expert
Licensed User
Longtime User
Hi all,
I followed the entire thread and I want to thank you all for the great job and achievements.
I'm not (yet?) in the BLE arena, but I found very instructive to read all your posts, so THANK YOU.
 
Upvote 0

red30

Well-Known Member
Licensed User
Longtime User
The oscilloscope is a great invention!
Having connected to the legs of the bluetooth module (TX and RX), I noticed that on the leg TX module bluetooth (RX microcontroller) only half the supply voltage. Parallel to the UART microcontroller, was connected the UART to 485 converter and, using a field-effect transistor, I turned off the power supply of this microcircuit when I worked with the Bluetooth module. So, the current flowed through it all the same, and therefore the TX bluetooth module had only half the supply voltage. This caused the long cycle of data exchange errors (the data just did not arrive normally). But the funny thing is that with Bluetooth 2.0 it worked fine and I did not pay attention to it.
I solder off the UART to 485 converter IC, and it all worked just fine !!
a0000ds-png.77973

As can be seen from the oscillogram, 40-60 ms pass between reception and transmission. This is certainly not very fast, but as I understand this module can not be faster (20 bytes every 20 ms). Perhaps somewhere else there is a delay in my program at b4a. Tomorrow I will see so much time running the program between receiving data, processing it, and sending the next request to the microcontroller.
The maximum consumption in the transmission mode was ~ 8 mA.
Later I will be able to give an electrical circuit principle, and I will point out my mistake there.

I tested the distance of this module and was disappointed. Maybe again I am doing something wrong, or somewhere an error has crept in ... The results are as follows:
RF power = 4 dBm
At a distance of ~ 25-30 m from the module RSSI bluetooth is -(90-95) and the connection breaks down. Although the documentation says that the maximum distance is 80-100m. Why can this happen?

vot.png
Do not do this!
If through the field-effect transistor to disconnect the converter UART to 485, then there will be a voltage drop by pin TX module bluetooth. After I solder off the UART chip in 485, a full power appeared on the pin TX bluetooth. Everything began to work normally.
 
Last edited:
Upvote 0

emexes

Expert
Licensed User
At a distance of ~ 25-30 m from the module RSSI bluetooth is -(90-95) and the connection breaks down. Although the documentation says that the maximum distance is 80-100m. Why can this happen?

That question made me laugh. Maybe I'm getting old and jaded, but... mixed in with all that experience are plenty of disappointing moments when I've discovered wide gaps (canyons, even) between what I've been told and what is reality. So now I've got an internal reality-adjustment-factor that I give people, and usually if someone says something is X then internally I prepare myself for it actually being (say) 0.8 X.

(Like, if my ex-wife says she'll arrive in ten minutes, then I know I've got heaps of time to go shopping, mow the lawn, have a coffee too ;-)

You can probably halve that reality-adjustment-factor again when it comes to your typical Chinese manufacturer and product specifications and labelling.

Plus specifications are always measured in ideal circumstances, and the range measurements and the reliability measurements were likely *not* done at the same time, whereas you are probably in an environment that has competing 2.4 GHz emissions coming from all directions. The RSSI is one factor of range, but another is the signal-to-noise ratio, and if there is a lot of noise about, then it will take less distance before your signal is drowned out by that noise. Like trying to have a conversation at a party, vs having a conversation somewhere quiet.
 
Last edited:
Upvote 0

emexes

Expert
Licensed User
The rest of your post was heartening, though, and I'm impressed and glad that you spotted that power supply issue. Fixing that can only make things better.

Speedwise, I think your best bet will be to send requests every slightly-longer-than-20-ms, and thus you should receive one response every 20 ms too. Although... what happens if timer ticks somehow bank up if something is hogging the CPU... can that happen? I don't know. Maybe the oscilloscope does ;-)
 
Upvote 0

emexes

Expert
Licensed User
I will point out my mistake there

Given that you found the mistake, and owned it (many would say nothing, blame it on the gods instead), and presumably won't be sprung by that trick again, then: it's not a mistake, it's a learning experience.

Any honest person on the creative side of working with technology will cheerfully admit that they too might have had one or two learning experiences in their time...

;-)
 
Last edited:
Upvote 0
Top