Make wireless proprietary data link

Hi, i have a device that communicate with the controller adopting a proprietary protocol, very similar to the one wire but is not the 1-wire. Is a bidirectional communication over a single wire, the controller send several bit and the device respond. The length of the single bit is around 50us, thus the frequency is about 20kHz. I have to replace the wire with a wireless channel. On transmitting and receiving side I already have two arduinos with Bluetooth modules Hc-05/06. I tried to acquire the signal packet with the Arduino with digital read, then send thought the Bluetooth and then recreate the signal on the other Arduino with digital write. The main problems are two:

  • For long stream of bit I loose the synchronism. To acquire I introduce a delay (about 50us) between the digitalreads, but, probably the delay introduced by the for loop and the digital read provoke the loose of synctronism.

-I introduce a significant delay because I first acquire all the bits (in some case more than 1000 bits) then I send all the data.

I also think to use two couple of RF module, but I try with H34A and similar but I have a lot of problems.
Do you have any ideas to suggest?
Thx!

Without knowing more about this bi-directional protocol, it is difficult to say too much.
I guess one device is the master and the other is the slave.
If the master transmits a command to the slave, it is prepared to wait only so long for a response until it retrys or gives up. If you are batching the response until you have a complete packet of frame, the master may, in the meantime, give up waiting.
Is it possible to stream the response instead of collecting an entire batch ?

What are these devices, incidentally ?

patrolgr88:
I already have two arduinos with Bluetooth modules Hc-05/06. I tried to acquire the signal packet with the Arduino with digital read, then send thought the Bluetooth and then recreate the signal on the other Arduino with digital write.

Without seeing your programs it is difficult to know exactly what you have tried.

It would also be a big help if you tell us what are the devices that are using this "proprietary protocol" so that we can understand your question in its full context.

...R

Indeed, need to know the device and preferably also the details of this protocol (which you appear to have figured out).

It seems you want to basically replace the wire with a Bluetooth link. So one thing to make sure of is that the Bluetooth link is faster than the wire link. After all you have to transmit your controller data + overhead over Bluetooth in less time than you need to talk to the controller, otherwise no chance to make it to work. The default 9600 bps Serial is no way going to keep up with a 20 kHz (so that'd be some 20,000 bps) link!

Thank you guys. The problem is that this protocol is used by a medical device and i haven't any information about the data protocol. I acquire the signal on the communication wire with a picoscope. A plot of the data is attached. the first burst is the data from controller to the device, the second is from the device to the controller (if i disconnect the device i have only the first burst ). I think that the real time is not very important, as said "6v6gt" the master will aprobably attend the response from the slave. However with my code (attached) occurs some errors after about 100 bits due to the synchronization problem (i use a delay from the first transition to 0, but probably the delay introduced by the code (for loop or the digital read) provoke a loss of synchronization). Do you have any suggestion to maintain the synchronization of the acquisition without using a fixed delay?

Test_tx_blue_LVAD_v4.ino (2.41 KB)

patrolgr88:
The problem is that this protocol is used by a medical device

Come on, we asked you what it is, you can't tell us what kind of medical device it is? Hiding information makes people suspicious that you're up to something no good. It's important because medicine is often that peoples lives depend on. Ever hear of a malpractice suit?

I'm not going to contribute advice about a medical project - there is a too great risk that I might suggest something inappropriate that could cause harm.

...R

Guys, the application is biomedical, an instruments that monitor the cardiac parameters, but mine is a universitary research project about the elimination of the power cable making the system fully wireless. Don't worry Is not a medical device for the life of the patient. It is only a research activites. The wireless power link works great but i wish try to replace also the phisical data link with a wireless protocol (if possibile).

Can you communicate with that device at all? As in, using wired connection to an Arduino?

Before you have that part fully working, it's no use even thinking about the wireless part.

but mine is a universitary research project

I'm surprised that your institution is happy with you hacking a proprietary protocol.

If it's a legitimate, university sanctioned research project, rather than hack the protocol why don't you get the uni to arrange a licence for you, and get the details of the protocol under nda from the owners.

twinkleyan:
get the details of the protocol under nda from the owners.

Ah, now where is the fun in that?

It might well be a research project ................

But whats going to happen when you publish the papers, are you going to own up to 'hacking' the interface of a piece of propriatry medical equipment ?

And acknowledge that the advice on how to do the 'hacking' came from a public forum ?

Do check where the funding sources of your university come from .........

Probably working on the typical hope that it's easier to get forgiveness after the fact, than to get permission first.

srnet:
But whats going to happen when you publish the papers, are you going to own up to 'hacking' the interface of a piece of propriatry medical equipment ?

Where's this "hacking" assertion coming from? From what I can tell, OP just wants to make a wireless bridge, not decode the protocol, lol.

I say just simply make a low power ASK radio transmitter/receiver pair and bridge the devices that way. Might even be able to use one of the el cheapo 433MHz radios for it with no need for an Arduino at all!

Power_Broker:
From what I can tell, OP just wants to make a wireless bridge, not decode the protocol

Fair enough...

Power_Broker:
Where's this "hacking" assertion coming from? From what I can tell, OP just wants to make a wireless bridge, not decode the protocol, lol.

At the very least the OP has to know:

  • what constitutes the transmission start/stop signals
  • how to encode/decode a 1 and a 0 on the wire
    Without that it's quite impossible to read, transmit and reproduce the signal correctly, or to switch from transmitting to receiving and vice versa at the appropriate times.

The decoding from bits to bytes to ascii characters or hex code is then trivial of course.

wvmarle:
At the very least the OP has to know:

  • what constitutes the transmission start/stop signals
  • how to encode/decode a 1 and a 0 on the wire
    Without that it's quite impossible to read, transmit and reproduce the signal correctly, or to switch from transmitting to receiving and vice versa at the appropriate times.

Except OP doesn't actually need to read and/or understand the waveform. Simply feed the waveform through a simple, low-power analog radio!

From what I see, nothing has to be decoded. Just replacing wires with wireless should just involve the appropriate wireless tx and rx interfaces. What is the wired configuration between the devices? Is the wiring similar to serial wired communications, or multiwire parallel port communications, or ethernet 8/4 wire setups? I don't see what part an arduino would play in this, unless there are other undisclosed things going on.

Power_Broker:
Simply feed the waveform through a simple, low-power analog radio!

In #0 the OP is talking about Bluetooth links.

I don't know of any suitable analog radios for that matter... haven't encountered them in the Arduino world, at least.

That protocol would have to be extremely tolerant to survive those attempts to tunnel it though a relatively low bandwidth link including batching a complete data frame, sending it over bluetooth, then unpacking it at the other end and recreating the electrical signals to match the input.

You might try sending each bit separately. Something like: mark:20uS space 20:uS mark:20uS space: 50uS etc from those electrical signals. Encode that. If you are lucky you have only 2 distinct mark/space pairs which you can encode as 0 and 1, then unpack that at the other end. The payload protocol would have to tolerate any latency in your data link for this to have a chance of working.

I could, however, also imagine directly using those input signals somehow to modulate the carrier of a simple radio link as has been already suggested.

You could also consider an infrared channel where the (currently) transmitting device would light an IR LED which would be received by an IR diode/phototransistor.

In both cases you would need additional logic to switch the single channel between receiving and sending.