Ultra low power Wired IoT Bus network

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
PeVo_1249246
Level 3
Level 3
10 replies posted 5 replies posted Welcome!

I have been inventing a ultra low power IoT Bus network that will outperform RS485/UART power consumption to about 40 times at 125kbps, does not need crystal stabilized timing, is physical fault proof, e.t.c. I want the bus network to become open standard. I have made several tests and made UDB component that performs the transaction on datapath and gate array level. Currently I have only tested it on PSoC 5 but would also like to port it to PSoC 4 with less capable UDB. The first test production evaluation boards with PSoC 5 are in production. I am looking for engineers who are willing to evaluate and participate the bus network development. More info about the evaluation board can be found at Wired IoT Bus Evaluation Kit – Tauria OÜ and Energy Consumption by Wired Internet of Things – Tauria OÜ .

Feel free to comment and ask questions !

5 Replies
PeVo_1249246
Level 3
Level 3
10 replies posted 5 replies posted Welcome!

We have published an article about the principle in Electronics Maker magazine. Published Ultra Low Power Wired Field-bus – Tauria OÜ See you at the Embedded World 2019 Exhibition Hall 4 / 4-682.

0 Likes

Peeter,

I'm still in the process of studying your "edge-event" communication protocol.  I like that you have put much thought into this topic.

At first glance of your discussion at Wired IoT Bus Evaluation Kit – Tauria OÜ and Energy Consumption by Wired Internet of Things – Tauria OÜ , I have some comments.

I've been working with various types of wired communication protocols for over 37 years.  They all suffered from one thing: Wires!

A wire protocol can be a potentially more reliable communication over wireless as long as you take into account the 'physics' of the properties of wires.

There are many factors limiting the performance of a wired system both in speed, reliability and as you are trying to address the power consumption.   

As my tag at the bottom of this post says:  "Engineering is an Art. The Art of Compromise."

It's usually the balance of multiple design factors that allows an engineer to reach the "state-of-the-art".

Bus Daisy-Chaining

Without a good serial device-to-device daisy-chain wiring technique, the bus will exhibit stub reflections along each connection.  This is why PCB designers are encouraged to place bus drivers and receivers as close as possible to the bus wire attachment on the PCB.

Excess wire length on node stubs will cause the "eye" pattern to see extra transitions which get added to the delayed original signal.  This can cause extra input transitions on down-stream receiving nodes.

Bus Termination

Bus termination is a special case of Bus Daisy-chaining.  Without terminating at the characteristic impedance of the bus (anywhere from 150 ohms to as low as 50 ohms), the driven signal can get reflected back to the source.   Since the termination is place at the very end of the bus, an unterminated bus will cause reflections with the greatest possible signal delay from the source.  This will further impact the "eye" negatively.

You can't avoid some energy consumption during switching states.  I believe this is what you are attempting to achieve with your proposed protocol.

Sadly, placing an equivalent of 50 to 150 ohms of resistance on the bus WILL consume energy in non-switching states (constant '0' or '1').  This is what you were trying to avoid.   This is especial true when the IoT nodes are idle >90% of the time.

The longer the bus and/or the faster the bus data rate, the more crucial the termination resistor becomes.   

Possible cases for not having a termination:

  • If you have a relatively short wired bus, the reflections may be inconsequential.   
  • If you're datarate is slow and you have a slew rate control (ie.  Through in some series resistance at the driver.  This in combination with the bus capacitance will slew rate control).

BUS Loading

Each bus has its maximum node limit.  This is because the signal drivers can only transmit so much current on the bus before the high signal voltage level drops below the high threshold detection of the receivers.

Adding a termination resistor lowers the maximum node limit.

BUS Collisions

If two or more nodes are attempting to communicate at the same time, this will most likely cause a signal collision.  A bad signal collision is where one or more drivers are trying to signal a '1' and one or more drivers signaling a '0'.  This will appear as a 'short' to all active drivers.  A good bus driver should not  become damaged if there is a short (or collision) on the bus.  The protocol should also be able to detect that a collision occurred and the usual strategy is for each node to back off the bus for a 'random' time.

BUS Environmental Interference

Although wired buses are much less prone wireless to external environmental interferences, it is still possible.   

There are many solutions to limit transient interference. 

With unbalanced signaling, it is common to use shielded coaxial helps with the GND as the shield.

Another very common method is to use a differential signal (also called balanced signaling) approach.  Ie.  You have the signal ('+') and the inversion of the signal ('-').

Then you use differential receivers to extract the signal for the CPU logic.  This helps filter transients in case it appears only on one side of the differential signal.

With the use of differential signaling, twisted-pair bus wiring is commonly use to further minimize environmental transients.

Len
"Engineering is an Art. The Art of Compromise."

Peeter,

I'm sorry for the "long-winded" post earlier.  I expect you're quite familiar with much of the discussion in the post.  I was aiming it primarily to others monitoring this thread who may not have as much experience with bus design principles as you or I.

If I am correct, the main goal of your protocol is to reduce lifetime power consumption so that IoT devices on the bus can have long life.   

Allow me to make a few suggestions.   These suggestions are based on the premise that your IoT bus can be dormant for extended periods of time.  This is where your bus will be idle for let's say: 90% of the time.

Let me start by discussing what the CAN bus does to minimize power.

The CAN bus can be placed be in a low power consuming state for as long as the bus is 'asleep'.  The CAN bus is commonly found in vehicles.  Since a vehicle can be not operated for hours if not days, this is crucial to prevent excess battery drain.

When the CAN bus is needed,  a "high-voltage" wakeup HW signal and "HW wakeup" message is placed on the bus.

On your bus, you can have a termination (let's say 120 ohms for twisted-pair) and a higher value (let's say 100Kohms) bias resistor to GND.

The terminator only get's powered when the bus is awake (via a '1' placed on the bus for 1us),  With the termination, the bus can operate at a higher speed with minimal 'eye' distortion.  Once no further traffic is detected within 'x' amount of time, the terminator power is switched off.

In addition at sleep, ALL nodes on the bus must set their drivers to tri-state.

The bias resistance to GND is always on the bus but is fairly insignificant to the overall power consumption.  This bias is designed to bias what would be a floating bus to '0' to help minimize false bus wakeups.   The value of this bias resistance would have to be determined by compromise.   A higher value would lower the potential power consumption but be more prone to external environment EMI that might be present.

In general, the switchable termination is only turned on when the bus is active.   Therefore only then does the drivers see ~120 ohms.   When the bus is asleep, the bias resistance to GND shouldn't see all but probably a few uA of current flow.  This would be due to accumulated leakage from the tri-stated drivers on the bus.

Len
"Engineering is an Art. The Art of Compromise."
Jostikas
Level 1
Level 1
First like received First reply posted Welcome!

Is there a collision detection/avoidance mechanism? At first I considered CAN-like collision avoidance, but that explicitly requires pulses to be long enough for the possibility of the farthest node on the bus to override it, and the bipolar driving of the bus would result in an electrical collision during the pulse duration.

PeVo_1249246
Level 3
Level 3
10 replies posted 5 replies posted Welcome!

Sorry for the late reply. I try to answer the questions in free form:

1. Reflections- the experiments have revealed that the reflections are not an issue since the the information is carried by the first front of the pulse and thus at the speed of light. All reflections will arrive after the signal has been delivered. The pulse is short and all reflections are consumed at least one terminator on the bus before the time for next pulse. This one terminator may be inside master device.

2. Collisions - I have been thinking about it, there are possibilities but I see this technique to be useful on low speed master - slave topology. So, the collisions could be avoided by the master orchestrating the communication.

0 Likes