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.

BobW

Active Member
I have some instrumentation mounted on a piece of rotating equipment, and I need to transfer data from the rotating instrument to a stationary processor. I have been using a slip ring previously to get the data out, but these things are not overly reliable. I'd like to switch to RF for data transfer, and I know there are all kinds of short range RF devices out there, but I've never used any of them. So, I'd like to get some advice.

The instrument will transfer a data packet of about 500 bytes every 5 seconds. The data has a short useful life. So, if the receiver fails to receive it, there is probably no need to resend it; the receiver will simply wait to receive the next data packet. I already have a low end PIC processor on the rotating instrument, and would like to use RF hardware that's compatible with it. That is to say, I don't want to use any complex protocol if I can avoid it. The exception is, if I can wrap the data inside a simple UDP packet using a bit of boilerplate code, which in turn could be picked up by a wifi router (or some other wifi transceiver), then that would make the receiving side of the project very simple.
 
As you mention WiFi, I would concur with the ESP8266, however I would also like to point out that you could 'dump' the PIC processor and use the one on the ESP8266 instead, which is far more powerful - but it depends what you're doing, as it lacks some peripherals that the PIC has.
 
bluetooth low energy is a fairly cheap option with very low power requirements.
if you dont know how to use it there are a few arduino modules. otherwise there are a bunch if ic's both with and without a internal uc.
 
The ESP8266 looks to be exactly what I need. Thanks. I've downloaded the reference data for the ESP8266 and for the ESP-01 boards, and I'm reading up on them now.

bluetooth low energy is a fairly cheap option with very low power requirements.
if you dont know how to use it there are a few arduino modules. otherwise there are a bunch if ic's both with and without a internal uc.
Bluetooth would probably be okay, except that I already have wifi on the receiving end, and would have to add extra hardware if I went the Bluetooth route.
 
I use the Wemos mini (ESP8266 based) to connect to my WiFi and serve a html page to display temperature and humidity (sensor connected to the Wemos) readings on the page.

Mike.
 
The ESP8266 looks to be exactly what I need. Thanks. I've downloaded the reference data for the ESP8266 and for the ESP-01 boards, and I'm reading up on them now.

I would suggest you get a WEMOS D1 Mini (or two) as well, these are more functional then the ESP-01's, and you can use them to more easily develop a design that you finalise with the 01.
 
Thanks. I'll check out the Wemos D1, but I'm not sure that it will offer me any more features than I need.

It looks like the simplest solution is to drive the ESP-01 with serial data from the existing PIC using the AT commands. I understand that it might be possible to put the complete application into the ESP8266, but it's not in the plans at the moment. The learning curve to do that would be huge.
 
It looks like the simplest solution is to drive the ESP-01 with serial data from the existing PIC using the AT commands. I understand that it might be possible to put the complete application into the ESP8266, but it's not in the plans at the moment. The learning curve to do that would be huge.

What is the PIC doing?, and what language is it programmed in?.
 
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.
 
As an aside, if you want to get a couple more IO pins on ESP8266-01 boards, you can break them out by lengthening the header pin footprint and adding a couple of bodge wires:
 
you could also use inductive coupling, where you have a circular coil on the rotating part, and another circular coil stationary, but around the moving coil. i don't know what the data rate is that you are looking for, but if you ran something like PSK or FSK at 20khz you could get a decent data rate.

something like this:
tx-rx-on-rotating-armature.png
 
This is a very harsh environment. I think it would be too difficult to protect something like that from damage. Assume that a deranged mechanic will attack it with a sledge hammer. Larger assemblies make larger targets for the evil mechanic. I'm not joking. Smaller devices can be protected in thick fiberglass enclosures, and may fly under the evil mechanic's radar. Even so, we have to expect to replace them every few weeks as part of standard maintenance.
 
I'm curious, what device is targeted by evil mechanics and needs replacing every few weeks?

Mike
 
If your mechanics are becoming evil, maybe it's best to try and understand the reasons why and mitigate any damage they might cause, because the amount of tools at their disposal is generally humongous. Mechanics are normally very resourceful...if that bolt can't be forced in with hand tools, the Snap-On 4 X torque-multiplier will do the job.
 
I'm curious, what device is targeted by evil mechanics and needs replacing every few weeks?
Essentially, anything that gets in the way of their sledge hammer. That's not to say that they're targeting the instrumentation specifically, but the instrumentation often gets in the way of some heavy duty mechanical part that needs to be adjusted with a sledge hammer. I'd better not say any more than that, in order to protect the guilty.
 
yes it probably should have an idiot proof design, and that's difficult because idiots can be so damned clever, and in this case armed with sledge hammers as well.
 
Essentially, anything that gerats in the way of their sledge hammer. That's not to say that they're targeting the instrumentation specifically, but the instrumentation often gets in the way of some heavy duty mechanical part that needs to be adjusted with a sledge hammer. I'd better not say any more than that, in order to protect the guilty.
Seems like you're implying all mechanics are akin to chimps, indiscriminately banging away at anything and everything, with scant regard for delicate electronics in the vicinity.
 
Not all mechanics, just one or two in particular.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top