Hello Everyone....!!!
I am trying to develop ESP Wroom 32 based IoT Gateway,
where Initial configuration of device (like name, some parameters, settings, etc) are to be done
by an Android app. Both ESP firmware and Android app are in draft documentation and development stage.
Since this is our first development with ESP, don't have much exposure to all standard practices and efficient methods.
I want suggestion on how should be data exchange between ESP 32 and Android App.
Plan is to connect ESP and App on Wifi. So what form should be the data exchange? Like simple string based CSV format
or is there any standard protocol or method we should use?
Suggestions on top of the above request are welcome from all you experts...!!!
Thanks for help in Advance..!!!!
Prefered Communication Form (Protocol) for Data exchange between Android App and ESP32
-
- Posts: 2
- Joined: Wed Mar 31, 2021 10:09 am
Re: Prefered Communication Form (Protocol) for Data exchange between Android App and ESP32
Well it depends on your bandwidth needs/requirements.
BLE/BT would be a good starter using SPP if linking to a phone. Look at this way, how may Phone periperals use Wifi?
Why do you think Wifi? If point to point then BLE/BT might be better.
Regardless of transport link you need to be clear about latency & bandwidth constraints.
I have posted on this point before if you wish to read.
Most people will be happy broadcasting with the odd lost packet of data. In which case your Wifi solution might send UDP and your BT/BLE solution would stream packets via SPP (with stream checksums).
There is no universal solution. Bandwidth, latency etc matter. Think logger (all data needed) or user interface (reactive display).
BLE/BT would be a good starter using SPP if linking to a phone. Look at this way, how may Phone periperals use Wifi?
Why do you think Wifi? If point to point then BLE/BT might be better.
Regardless of transport link you need to be clear about latency & bandwidth constraints.
I have posted on this point before if you wish to read.
Most people will be happy broadcasting with the odd lost packet of data. In which case your Wifi solution might send UDP and your BT/BLE solution would stream packets via SPP (with stream checksums).
There is no universal solution. Bandwidth, latency etc matter. Think logger (all data needed) or user interface (reactive display).
& I also believe that IDF CAN should be fixed.
-
- Posts: 2
- Joined: Wed Mar 31, 2021 10:09 am
Re: Prefered Communication Form (Protocol) for Data exchange between Android App and ESP32
Hello Peter,
Highly appreciate your clear cut and guiding perspective.
Your view is valid, how many peripherals use wifi?
I had no particular reason to use wifi. My rqeuirement is point to point only.
It is more of a Data Logger type. All data Needed.
I couldn't locate your topic post in this relation which you mentioned.
You seem quite active and i saw 62 pages to scroll through and filter.
Can you post a link here in discussion?
Also if you have any helpers and pointers further on BT/BLE using SPP,
please share those as well.
Thank you so much...!!
Highly appreciate your clear cut and guiding perspective.
Your view is valid, how many peripherals use wifi?
I had no particular reason to use wifi. My rqeuirement is point to point only.
It is more of a Data Logger type. All data Needed.
I couldn't locate your topic post in this relation which you mentioned.
You seem quite active and i saw 62 pages to scroll through and filter.
Can you post a link here in discussion?
Also if you have any helpers and pointers further on BT/BLE using SPP,
please share those as well.
Thank you so much...!!
Re: Prefered Communication Form (Protocol) for Data exchange between Android App and ESP32
I think my earlier posts will just repeat what I said.
SPP is an ESP BT example I think.
There is not a BLE SPP profile. There are plenty of examples about emulating SPP over BLE however.
I seem to remember that I copied an STM32 application guide. This coupled with the ESP examples gave me the means to impement the profile.
I would suggest starting with BT. Once you understand BT you will be better able to understand the details in making a BLE custom profile.
You should check delivery guarentee when using SPP, my BT is rusty & I just did not need guarenteed delivery (RT streaming rather than logging).
Wifi (e.g. TCP) gives you guarenteed delivery (or connection fail) but might go lagging from time to time when retransmitting.
IJDK if all BT SPP TX frames are RX guarenteed. I think so because I used as a round trip design test. Check.
Wifi might well give you easier application point to point guarentee.
But I think perhaps you can tolerate the occasional loss of data. I have designed/implemented Avionics loggers (iNET-X) which is a UDP multicast protocol and so cannot guarentee that all data has been logged.
Be aware that both libraries are resource hungry although ESP have done much to reduce footprint.
SPP is an ESP BT example I think.
There is not a BLE SPP profile. There are plenty of examples about emulating SPP over BLE however.
I seem to remember that I copied an STM32 application guide. This coupled with the ESP examples gave me the means to impement the profile.
I would suggest starting with BT. Once you understand BT you will be better able to understand the details in making a BLE custom profile.
You should check delivery guarentee when using SPP, my BT is rusty & I just did not need guarenteed delivery (RT streaming rather than logging).
Wifi (e.g. TCP) gives you guarenteed delivery (or connection fail) but might go lagging from time to time when retransmitting.
IJDK if all BT SPP TX frames are RX guarenteed. I think so because I used as a round trip design test. Check.
Wifi might well give you easier application point to point guarentee.
But I think perhaps you can tolerate the occasional loss of data. I have designed/implemented Avionics loggers (iNET-X) which is a UDP multicast protocol and so cannot guarentee that all data has been logged.
Be aware that both libraries are resource hungry although ESP have done much to reduce footprint.
& I also believe that IDF CAN should be fixed.
Who is online
Users browsing this forum: No registered users and 58 guests