I would like to send and receive large amount of data from an external device to/from the esp32 so the later one can send/receive via wifi. I though to use the SPI as it can handle high frequency rates (documentation say stable frequency 18Mhz). The question is if it would be possible to do so? If not, what would be the best way to exchange data with external devices then?
Thanks for any tips
Related
I want to calculate internet speed in embedded device. In my researches on the internet, I saw that in order to measure internet speed, I had to download data from a server and calculate according to the download time. But this creates a lot of data usage and tires the device. Are there any other methods I can use other than that?
If there is no other way, What is the optimal data size to download from server?
Thank you.
I think it's the only possible way to test data transfer, at least correctly. Simple ideas that can be used as speedtest:
Load image(s), check when it's fully loaded and calculate time difference divided by image size.
Make GET request which responds to you with desired chunk of data and on response calculate difference divided by response size.
Create POST request and send randomly generated data in it and on response calculate difference divided by image size.
Create websocket and send ping->pong messages. (Websocket used instead of HTTP request because of its lower latency and stability)
You should also take a look that in all of those tests data compression and caching should be disabled and that they may be affected by ping.
I am sorry but there isn't an "Internet speed" because devices and applications do many things on Internet. You should start understanding and explaining what your device does and what you are trying to measure. If your device receives a video stream, you are not interested in the TCP bandwidth or latency. If your device sends small data packets against one server, you should test the average response time between your device and that server with messages roughly the same size.
Moreover, an embedded device is often limited and should not be used to measure because you cannot say if the speed is throttled by the network or by the device itself. So, you should replace your device with a fast-enough pc.
If the device uses a wireless network (wifi, 4G, ...) the speed can be variable and you should take many measures and calculate an average
I am using Estimote beacons to determine if something moved. This is done by monitoring which beacons are in range (MonitoringListener) and which beacons have moved (TelemetryListener).
The problem is EstimoteTelemetry has a field UniqueId but Beacon uses UUID, Major and Minor to determine the unique beacon. EstimoteTelemetry does not broadcasat UUID, Major and Minor..
I need to know which beacon is broadcasting the telemetry packets. I can't see any fields that are the same in both. Anyone know how to do this on Android or iOS?
As you mentioned there are no data fields in the BT packets that are shared among iBeacon and Telemetry packets. These are completely independent packets and contain different set of information. It is not possible to use iBeacon identification in telemetry packet - it takes too much space so telemetry data would be extremely limited.
If you need to collect both packets and keep them together look-up table in your app/server is the only solution. Estimote does not provide this kind of functionality.
Each Estimote beacon has single non-changing identifier (16 bytes) assigned during production. Telemetry packet contains first half of it (8 bytes). You need to create table where this 8 bytes are related to exact iBeacon identification you use.
Tcp/ip is universal that suite for most of cases. And as a general solution it is not optimal for specific cases:
1) To transfer data over the continents with packet loss. (As example [Appera1, for some cases it makes transfer faster 10x times.)
2) For gigabyte LAN with no packet loss. Here TCP/IP intruduce overhead with ACK and things that are for long dinstance and slow networks. I remember that read about some protocol for gigabyte LAN that is significantly faster than TCP/IP.
The last one is interesting for backup the solution that should transfer huge amount of data. What do you know about alternative network data transfer protocols for windows?
If you are doing backup, I'm guessing #2 is the case you're concerned about.
TCP has several optimizations to address #2: sliding windows, windows scaling, and fast retransmit and recovery if congestion should occur. As long as the receiver's window is open, ACKs don't gate the effective bandwidth.
Since this question is on SO, I'm assuming programming is involved, so in implementing your receiving program you can keep window open by providing large buffers. Use the bandwidth-delay product in determining buffer size. You can dynamically compute this, or if your environment is stable, then you can use a static calculation.
Regarding windows protocols you have two choices. "In the box" and 3rd party. You can view in the box protocol by going to Control Panel, Network, Change Adpater settings (for your gigE adapter), Properties, Install, Protocol. On my 2008R2 system I only see Microsoft Virtual Switch Protocol, and Reliable Multicast Protocol. Neither would help unless you want to backup to multiple locations simultaneously (using multicast).
As far as 3rd party protocols go, that's really beyond the scope of SO. A couple of well chosen web searches will fill the bill for that.
And if you're going for absolute fastest speed and your backup source and target are in same broadcast domain, you can skip IP altogether and program at the MAC layer. You'll lose a lot of functionality, but if you do it well it'll be fast.
I am using a 32-bit AVR microcontroller (AT32UC3A3256) with High speed USB support. I want to stream data regularly from my PC to the device (without acknowledge of data), so exactly like a USB audio interface, except the data I want to send isn't audio. Such an interface is described here: http://www.edn.com/design/consumer/4376143/Fundamentals-of-USB-Audio.
I am a bit confused about USB isochronous transfers. I understand how a single transfer works, but how and when is the next subsequent transfer planned? I want a continuous stream of data that is calculated a little ahead of time, but streamed with minimum latency and without interruptions (except some occasional data loss). From my understanding, Windows is not a realtime OS so I think the transfers should not be planned with a timer every x milliseconds, but rather using interrupts/events? Or maybe a buffer needs to be filled continuously with as much data as there is available?
I think my question is still about the concepts of USB and not code-related, but if anyone wants to see my code, I am testing and modifying the "USB Vendor Class" example in the ASF framework of Atmel Studio, which contains the firmware source for the AVR and the source for the Windows EXE as well. The Windows example program uses libusb with a supplied driver.
Stephen -
You say "exactly like USB Audio"; but beware! The USB Audio class is very, very complicated because it implements a closed-loop servo system to establish long-term synchronisation between the PC and the audio device. You probably don't need all of that in your application.
To explain a bit more about long-term synchronisation: The audio codec at one end (e.g. the USB headphones) may run at a nominal 48KHz sampling rate, and the audio file at the other end (e.g. the PC) may be designed to offer 48 thousand samples per second, but the PC and the headphones are never going to run at exactly the same speed. Sooner or later there is going to be a buffer overrun or under-run. So the USB audio class implements a control pipe as well as the audio pipe(s). The control pipe is used to negotiate a slight speed-up or slow-down at one end, usually the Device end (e.g. headphones), to avoid data loss. That's why the USB descriptors for audio device class products are so incredibly complex.
If your application can tolerate a slight error in the speed at which data is delivered to the AVR from the PC, you can dispense with the closed-loop servo. That makes things much, much simpler.
You are absolutely right in assuming the need for long-term buffering when streaming data using isochronous pipes. A single isochronous transfer is pointless - you may as well use a bulk pipe for that. The whole reason for isochronous pipes is to handle data streaming. So a lot of look-ahead buffering has to be set up, just as you say.
I use LibUsbK for my iso transfers in product-specific applications which do not fit any preconceived USB classes. There is reasonably good documentation at libusbk for iso transfers. In short - you decide how many bytes per packet and how many packets per transfer. You decide how many buffers to pre-fill (I use five), and offer the libusbk driver the whole lot to start things going. Then you get callbacks as each of those buffers gets emptied by the driver, so you can fill them with new data. It works well for me, even though I have awkward sampling rates to deal with. In my case I set up a bunch of twenty-one packets where twenty of them carry 40 bytes and the twenty-first carries 44 bytes!
Hope that helps
- Tony
this might be a stupid question to some but allow me to ask, does a type of a certain device affect the bandwidth and data transmission? Say for example does a tablet's bandwidth differ from a PC's given that they have the same bandwidth from the router? Thanks in advance for those who will take time to answer. :)
If you're talking about the data transfer speed, not materially. As long as the device is fast enough to keep up with the incoming data (a cheap tablet with a slow processor might not be able to process a full HD video stream, for example), the device type doesn't matter. What matters is the network connection, though for wireless better chipsets (e.g., Intel's) will often have better performance than cheaper ones under the same conditions.