Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Looking for a short distance RF data solution

Status
Not open for further replies.
Train 'em then, or send 'em packing when proven to be un-trainable.
 
Among other things, it's reading an encoder, scaling the encoder value to a different range and outputting it to another device on the fly. It's coded in assembly language. Coded in anything else, it wouldn't be fast enough. I guess I could offload everything except the encoder processing to the ESP8266.

An encoder is a mechanical device, so presumably fairly 'slow'?, in any case the ESP8266 is a VERY fast processor, much more than a low end PIC - and C++ on an ESP should be faster than assembler on the PIC (much as I love PIC's :D).
 
The encoder is not a fast device, but latency is critical. The PIC needs to read/convert/output as fast as possible so that the destination instrument is getting the encoder position before things have moved significantly. Despite claims that C type compilers produce very efficient code, I generally see a minimum factor of 10 degradation compared to assembly language, and in this case I would expect it to be considerably worse, because I've optimized the size of the data words and operations for this specific task, and the code does things that can't be replicated efficiently in C. So, I don't know that the ESP8266 would give that much speed improvement. I'm also concerned that the latency should be as constant as possible, and I don't know if that could be guaranteed on a chip like the ESP8266, which is doing a lot of different things at the same time. In the end, since it's already working in the PIC, it comes down to "If it ain't broke, don't fix it." So, I'll leave the encoder stuff in the PIC, for now at least. Having one extra inexpensive chip in the circuit is no big deal.

Meanwhile I've ordered a couple of Wemos D1's as well as the ESP-01's.
 
If you want to avoid latency then look into a rs232 wireless solution. A couple of bluetooth modules (HC05) should work fine.

Mike
Edit, the HC06 can only operate as a slave - the HC05 can be both master and slave.
 
Last edited:
I think maybe I confused the issue by bringing up the encoder processing. That operation is completely unrelated to the wireless data transfer. Please forget that I ever mentioned it. Latency isn't a problem with the wireless data, because it's timestamped.
 
I think you're on a good path here, using the PIC you already have and integrating with the ESP.

The ESP is really fast, but due to the nature of Wifi and the connection handlers, and after everything you've said, I'm not so sure I trust it to be deterministic to use it as your sole processor. Especially if its trying to connect to an access point which it can't find anymore, it can cause the ESP processor to really hang up for the other tasks. You can obviously set priority on tasks to try to overcome the majority of timing issues, but I still would feel a little uneasy, especially if you're using the Arduino environment which adds another abstraction level.
 
Several months later…
A brief update:
I chose the "slow boat from China" shipping method. So the modules didn't arrive until late summer, and then I was busy with other things until a few days ago. I bought both the ESP-01's and the WEMOS D1's as recommended, but I ended up doing the development on the simpler ESP-01. The principal difference is that the ESP-01 is serial only, and the WEMOS is USB. Since I have a few FTDI adapters on hand, there was no trouble interfacing between my computer and the ESP-01. Initially, I worked with the pre-flashed AT command set that the ESP-01 came with. This was very handy for initially getting things communicating and proving out both the serial and wireless end of things. After that, I found an Arduino example project that was close to what I needed. So I modified that, and after a minor amount of debugging, it's now doing exactly what I wanted.

This was my very first Arduino project, and I don't have much C programming experience. So, I was a bit apprehensive. However, things went surprisingly well. If I had any complaint, it would be the lack of a good single source of documentation online. There's a tremendous amount of incomplete and incorrect ESP8266 documentation out there, and I had to sort through a lot of it before I got to the point of connecting the hardware and starting the programming. Even so, it all turned out well, and I'm already thinking up some new projects. So, thanks everyone for the suggestions to use the ESP8266.
 
FYI, the Wemos mini runs at 80MHz, has 4meg flash and 82k ram. It's a very powerful board. Add a 32G SD card and you'll never run out of space. Well worth getting better acquainted with.

Mike.
 
I'll definitely use the Wemos D1 in some upcoming project. I have two of them, and four ESP-01's. So there are lots for me to play with. The Wemos D1 would have been overkill for this project though.
 
See if you can get a library for the Nfc protocol used by mobile phones, the hardware is just a cap and a coil.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top