Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Micro-controller connecting to websocket server trough GSM / 3G module

Status
Not open for further replies.

untampit

Newbie level 3
Joined
Jun 25, 2012
Messages
3
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,301
Is it possible ?
Any ideas how it can be done ?

I need to send data as fast as possible to a web-server from my mcu, and I guess using websockets is the best way, because the connection is open always, it doesn't have to be initiated before each data transfer. Am I right ?

Thank you
 
Last edited:

What kind of data is it? Bear in mind that usually latency is not an issue here, because whoever is using a web browser to access the
application on the web server isn't functioning in the same level of "real time" as you might think (If you're sending voice or video in real-time,
then that's a different thing. So knowledge of the type of data is important). For normal data, there is some delay when
accessing a web application (not saying that it is a good thing, but what I mean is, are you sure that your choice of using websockets will eliminate
a bottleneck?). Personally, I would try to ensure that I don't need to send so much data that the throughput becomes the bottleneck.
What I mean is try to design your system so that it sends an appropriate amount of data for the particular application you're working on, and
make your application work appropriately. An example is: say you had a system that allowed you to adjust frequency with a tuning knob.
Translating that to a web-based application, a first effort might have up/down boxes to click in a web page, and your websocket connection would
be sending up/down characters and you'd be receiving a frequency value back, which you'd send to the client to be displayed in the web browser.
That's not great, because you may have significant delays using 3G and the internet.
But a better solution would be to have a box in which the user types a frequency and clicks 'set', and then a single request gets sent to the
microcontroller. Until the response is received, the browser can display "please wait...".
Then, that means you could possibly rely on conventional HTTP. Sure there is a TCP setup overhead, but non-embedded apps manage just
fine. Anyway, that's just a personal opinion.
 

What kind of data is it? Bear in mind that usually latency is not an issue here, because whoever is using a web browser to access the
application on the web server isn't functioning in the same level of "real time" as you might think (If you're sending voice or video in real-time,
then that's a different thing. So knowledge of the type of data is important). For normal data, there is some delay when
accessing a web application (not saying that it is a good thing, but what I mean is, are you sure that your choice of using websockets will eliminate
a bottleneck?). Personally, I would try to ensure that I don't need to send so much data that the throughput becomes the bottleneck.
What I mean is try to design your system so that it sends an appropriate amount of data for the particular application you're working on, and
make your application work appropriately. An example is: say you had a system that allowed you to adjust frequency with a tuning knob.
Translating that to a web-based application, a first effort might have up/down boxes to click in a web page, and your websocket connection would
be sending up/down characters and you'd be receiving a frequency value back, which you'd send to the client to be displayed in the web browser.
That's not great, because you may have significant delays using 3G and the internet.
But a better solution would be to have a box in which the user types a frequency and clicks 'set', and then a single request gets sent to the
microcontroller. Until the response is received, the browser can display "please wait...".
Then, that means you could possibly rely on conventional HTTP. Sure there is a TCP setup overhead, but non-embedded apps manage just
fine. Anyway, that's just a personal opinion.


Well, i have to send commands to my MCU, and it must reply with an answer as fast as possible.
Also the MCU can send commands to the serv, and the serv must reply as fast as possible....
What would be the best way ?

- - - Updated - - -

Data is in hex format, and is splitted in chunks of 150KB , 3 chunks every 5 minutes.
The chunks include traffic back & forth
 

You need to try to figure out where your delays will be. there will be 100s of millisec of delay regardless of your choice of protocol
(websockets or not), if you're using an internet connection over 3G - and the user with the web browser may be over an even slower
link, maybe dial-up.
You can't assume you can eliminate these delays, so design so that the delays don't matter - e.g. send an instruction to control a servo
at a specific time, i.e. scheduling in advance, if time is that critical.
Controlling a servo shouldn't need 150kB, so I guess there is additional data in there.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top