Wireless PAB Extension

[CaptCrash]

Is anyone interested in being able to make connections of their PAB devices over a Wireless link?

I have a prototype that is working of a wireless extender that allows me to connect a PowerBar 6D PAB and an Expansion Box that are 20m away from the rest of my PAB network/P3Ex controller.
So far I have tested it in normal usage, performed a firmware upgrade over it to the PowerBar 6D PAB and it appears to work in a stable manner.

The first extender connects to my P3Ex with a PAB cable and then wirelessly to the second extender which is connected to the PowerBar 6D PAB with a PAB cable.
The wireless connection can operate on multiple channels so it should be possible to have multiple wireless connections, though I have not tested this as I only have a single link at the moment.
Each connection is a replacement for a cable, so you still need to attach to PAB devices at each end.

If people are interested in such a thing, I would be willing to put some more effort in, make it more of an item rather than just a hacked together piece of electronics modules.
Perhaps provide a DIY kit or similar to allow you to make your own.

Note: I am not looking to sell or provide this as a product. More I am just looking to get an idea if people are interested and if so Ill probably post up instructions etc.

[Halfmoon]

Interesting, would love to know more.

[Vinny]

This is an interesting concept indeed! Thank you for sharing your findings with us.

[doggydoc10]

Count me in


Always at sea;

Dr. Antonio Longo

[SteveAtkins]

Sounds very interesting.

Steve

[Matthias]

I am not sure if there might be timing/latency problems or if it is possible that the data packets are mixed during transmission because I dont know the details of the used technology

but it sounds very interesting

do you mind to share some details?

[CaptCrash]

I thought I would post a quick update on this.

Im in the middle of a redesign on the device at the moment and am waiting for some parts to arrive (probably between christmas and new years now).
I have been missing some of the data on the PAB bus that has not affected the operation of the powerbar.
However when I started utilising features of the expansion box this showed up.
As I have not been decoding the details on the bus, I'm not sure if this was causing retransmits, errors etc

My V2 approach is to actually interact more directly with the PAB bus.
To that end Ill utilise MCP2551 and MCP2515 to decode the data, transfer that to the micro and then to the wireless.

This will provide me with a 2Mb/s full duplex connection between the micros and should allow for sufficient bandwidth to allow the extension of the bus.
In terms of data packet order, thats something I need to test, but even with my basic V1 design, didn't seem to be an issue.
Ill make sure I implement some sort of handling to ensure that packets are delivered in order across the wireless.

thanks for the tip.

regards

Darren

[doggydoc10]

I thought I would post a quick update on this.

Im in the middle of a redesign on the device at the moment and am waiting for some parts to arrive (probably between christmas and new years now).
I have been missing some of the data on the PAB bus that has not affected the operation of the powerbar.
However when I started utilising features of the expansion box this showed up.
As I have not been decoding the details on the bus, I'm not sure if this was causing retransmits, errors etc

My V2 approach is to actually interact more directly with the PAB bus.
To that end Ill utilise MCP2551 and MCP2515 to decode the data, transfer that to the micro and then to the wireless.

This will provide me with a 2Mb/s full duplex connection between the micros and should allow for sufficient bandwidth to allow the extension of the bus.
In terms of data packet order, thats something I need to test, but even with my basic V1 design, didn't seem to be an issue.
Ill make sure I implement some sort of handling to ensure that packets are delivered in order across the wireless.

thanks for the tip.

regards

Darren


Thanks for the update. Looking forward to the next one.


Always at sea;

Dr. Antonio Longo

[CaptCrash]

All of the new parts have now arrived and have been hacked together.

My setup at the moment is as follows

http://i499.photobucket.com/albums/rr351/dnancarrow/Electronics/Wireless%20PAB/image2_zpsecqqj0nk.jpg

Unit 1 (top mess of stuff)
PAB Bus -> RJ45 Breakout board -> CAN Bus break out board -> Arduino Nanno -> RF24 wireless module.

Unit 2 (bottom mess of stuff)
RF24 wireless module -> Arduino Nanno -> LCD

With this new setup I have been able to achieve very reliable communications. The wireless link is 2Mb/s, the PAB bus is 1Mb/s.

I have built two test systems, in both cases the PAB data is transferred from the receiving unit (unit 1) via wireless to the display unit (unit 2).
Even without much optimisation, this looks to be substantially better than my original attempt. With lots of debug code and displaying details on both the LCD and serial console, I was able to transfer over 1.4 million PAB events with a loss of 3.
This test displayed the time and date on unit 2, by transferring all PAB data, from Unit 1 to Unit 2. Unit 2 then filtered all of the data for just the time events and displayed the time and date on the LCD.


http://vid499.photobucket.com/albums/rr351/dnancarrow/Electronics/Wireless%20PAB/Video_zpsnf7houbr.mp4
The video shows the display of the date/time on unit 1, later this display was moved to unit 2.

In my second test, I have optimised the code to do nothing other than transfer data between the two units.
With this test I am again transferring each of the PAB events from Unit 1 to Unit 2. Unit 1 is keeping track of how many events are being sent and adding this count to the time events as an addition to the PAB data.
Unit 2 receives all of the PAB events and counts them.
Unit 2 then displays the counts from Unit 1 and Unit 2 on the LCD and calculates the missed number of packets. At this point this test has been going for about an hour and has not missed a single event.

http://i499.photobucket.com/albums/rr351/dnancarrow/Electronics/Wireless%20PAB/image1_zpsxbhzsb4z.jpg
S = Sent packets
R = Received packets
0 = count of missed packets

My plan is to let this run over night and see how many packets are missed.

At this stage, no optimisation has been done for the radio communications, each PAB event is sent to the other side and an acknowledgement is returned from the recipient radio module.

[CaptCrash]

At this stage, this looks very promising.
I still have a couple of more tests to perform and some optimisation on the data format.

Optimisations that may deliver better performance include
1. Sending multiple PAB frames in a single radio transfer
2. Larger or Smaller radio packets
3. Radio power tuning for shorter distances
4. Radio channel selection
5. Code optimisation (or migration to native AVR rather than Arduino)
6. Other unthought of issues

Ill post up as I progress

[doggydoc10]

Wow.
Amazing. Can't wait to see what the next tests are.


Always at sea;

Dr. Antonio Longo

[CaptCrash]

Testing last night went very well.

2.5 million PAB events
Approx 10 hours of run time
1 retransmit (when I bumped the cables just after the test started)
0 PAB events lost

So I'm very happy with that.

[CaptCrash]

I now have successfully completed the initial programming and am starting to do some more complex testing.

My test for tonight is as follows

1. PowerBar 6D PAB (PAB address 22) connected to wireless unit 2
2. GHL Profilux PIII Ex, 2 x Powerboat 6D PAB, Expansion Box and Touch connected to wireless unit 1

All traffic from each side is replicated to the other side.
I used GCC to assign the Powerbar 6D PAB to the controller over the wireless connection.
I also used the controller to assign a PAB address
I then configured the following via GCC relating to the powerbar
Descriptions where then added to each of the S13 - S18 ports to identify them being used for this test.

The controller has been configured to turn on and off various sockets on the Powerbar 6D (PAB address 22) based on the following conditions

Socket 1 S13 Programmable Logic 14
Socket 2 S14 Programmable Logic 14 (Inverted)
Socket 3 S15 Always Off
Socket 4 S16 Illumination 1
Socket 5 S17 Illumination 10
Socket 6 S18 Always On

Programmable Logic 14 is Cyclic at 180 seconds (so it is cycling between on and off every three minutes)
S14 does the exact opposite of S13, in that one or the other is always on.
Illumination 1 is a channel for my main lights (off at night)
Illumination 10 is a channel for my Sump (On through most of the night and some of the day)

My wireless units are recording the number of retries needed for the wireless communications.
I also have two additional units configured on the PAB bus. These units are not transmitting via wireless, rather they are simply counting the packets that occur on the PAB busses. All four units are keeping these statistics, with the objective of seeing if any packets have been missed by the wireless units.

The Profilux is configured to email me on an error such as a PAB error. During my testing so far, I have regularly received error emails. As such I expect that if there are any issues tonight, I will receive error emails in the morning.

The following video shows the test setup, obviously its still just a hacked together thing, so it does look like a complete mess at the moment.


http://vid499.photobucket.com/albums/rr351/dnancarrow/Electronics/Wireless%20PAB/Video_zpsfpnyjbh9.mp4

Now that it is delivering on what I have been attempting, I will look to put some proper boards together and finalise the hardware design.

[CaptCrash]

The test last night went well.

Three packets were retransmitted over the wireless link and none lost over the 10 hour period.
No other issues were recorded, statistics from each of the four units match with the exception of the additional retransmit packets on the wireless.

My tasks now are to simplify the code and remove much of the debug information that is included (I will leave the traffic logging in the code for the moment), remove the LCD, button connectivity from the code and streamline the software.
Whilst Im doing this I'm going to design a PCB to host the various modules/components and get a couple built up.
I think I have enough parts to do six units (three wireless links).

So what Ill do is connect the it as follows

GHL Profilux PIII Ex -> Powerbar 6D PAB -> Powerbar 6D PAB -> Expansion Box -> Touch -> Wireless Unit 1 => Wireless Unit 2 -> Wireless Unit 3 => Wireless Unit 4 -> Wireless Unit 5 => Wireless Unit 6 -> Powerbar 6D PAB

-> represents a cabled link
=> represents a wireless link

This will let me test performance when utilising seperate wireless channels on the radios and verify if there is performance loss with the multiple links.

[doggydoc10]

Awesome.
Thank you for the report.
Looking forward to next phase


Always at sea;

Dr. Antonio Longo

[Vinny]

Glad to hear things are working out nicely.

Thank you for sharing your progress with us. :)

[CaptCrash]

No problem Vinny, I will keep updating this thread as I move forward/find any issues.

Im having an issue today with the multiple wireless links, I was hoping to be able to hard set them, but it looks like I get some interference on some of the channels from other devices in my area.

Luckily there are 128 channels to choose from with only about 15 being an issue (of course I was trying to use 2 of these), so Im adding a channel search function so each link can negotiate the best channel to operate on. I have some sample code that I can use as a base so it shouldn't be too much of an issue.

Can GHL provide details on the PAB protocol? eg. it would be good if I was able to filter the data going across the wireless link so that only information that needs to be transmitted is (in essence a bridge function if you are familiar with communications networks).

[Matthias]

Can GHL provide details on the PAB protocol?

Unfortunately not. We dont want that Jebao or similar companies start to copy our devices. As it happened with our Doser.


it would be good if I was able to filter the data

filtering makes no sense since we use all 29 Bits of the Message-ID, all of them can vary

[CaptCrash]

Ok, time for a quick update.
Not much progress this week as I have been working on other things.

Current task is to get the auto channel assignment working. I have it working as a seperate piece of code, but need to integrate it together.
I also have to clear out an issue I have introduced where I'm loosing some packets when I change channels. I think its just that I am changing channels without clearing the transmit queue first. Anyway more testing to do.

[CaptCrash]

Latest update.

The wireless link has now been operating since the 26.01.16 without the loss of a single packet (I found the issue I was having on the 25th). Ironically I had gone through the code and removed a lot of debug information. In some situations this was causing the master unit to return to its transmit mode before the slave unit was able to finish transmitting (Im not sure why I described it as changing channels, I think I may have been confused with the pipes roles in the process).

The units have now been enhanced with the ability to scan the wireless environment and exclude wireless channels where there other items are using the frequency (it does this for each possible link speed 250Kb/s, 1Mb/s and 2Mb/s as I found that testing only with the 2Mb/s speed missed some channels that were busy/noisy). It then will pick the highest channel without interference to use (I went for highest on the assumption that people are most likely to use the lower channels). This is also user selectable via the menu.

I envisage the usage to be, 1. Run a Radio Scan on the master unit. 2. Set the Slave unit to the chosen channel manually.

At the moment you can browse the menu without affecting the performance of the link. However if you want to change a setting, then the link will be stopped from when you change the setting until the unit restarts to implement the new setting.

You can change multiple settings, then perform a single Save Settings.
During this period the Profilux will report a PAB error as the Wireless link is down.
Once the link is back up, the Profilux with report the PAB error as cleared.
This is the same as if you removed the PAB cable and then reconnected it.

A menu is included that allows the selection of the following
* Radio Channel (128 channels, default 1)
* CRC length (disabled, 8 bit or 16 bit)
* Radio transmit power (min, low, high, max)
* Radio Retries (1-15, default 2)
* Auto Ack (On Off)
* Radio Delay on Retries (250uS - 4000uS, default 500uS)* Master or Slave operation, either end of the radio link
* LCD Display timeout, turns off backlight and displays time and statistics once time is up rather than the menu (0-180 seconds, default 10 seconds)
* Save Settings
* Factory Reset
* Radio Scan

Note: default settings are bolded above, if you run a Factory Reset, this is what will be set.

Outstanding tasks
* Improve the button performance in the menus, attempt to allow settings changes without stopping radio link operation (until the save settings and restart are performed)
* Update the Transmit/Receive pair addresses based on the channel selection (currently to use more than one radio link, these addresses need to be changed per pair in the source code)
* Route a final PCB, design a case and mount the hardware, I am 1/2 way through doing this, I need to finish routing the PCB, then test fit the components, solder it up and confirm it works (or fix what doesn't). Then design case to suit the final structure.
* Additional documentation into source code
* Provide some sort of a build set of instructions
* Publish source code, schematics, bill of materials etc

In terms of components/modules its mostly stuff you can purchase pre-assembled. All that is needed is to solder the bits together with wires.
I would prefer to build a board that will allow the various modules to be plugged in with a minimum or no soldering required as this will end up being more compact and I can then seal it against the elements.

I have used the following for each radio link (2 ends)
2 x Arduino Pro Mini (5V 16MHz)
2 x NRF24L01+ modules with an added capacitor each
2 x NRF24 adapters (5v -> 3v)
2 x CAN_Bus Modules with an added resister each
2 x 16x2 Serial LCD (parallel LCD's could also be used with a code change)
2 x 5 Way joystick or 10 x push buttons with 10 added resisters (it is likely to reduce this to 6 push buttons with 6 added resisters)
2 x 5V power supply
2 x RJ45 socket
2 x Power Jack

[CaptCrash]

Well the project is getting a bit closer to being complete.

Of the outstanding tasks, I have most of them now complete

Buttons/Menu Systems
The buttons and the menu now operate without impact on the operation of the radio link. Changing settings still requires a restart and this will interrupt the link, but otherwise, everything operates on a reliable basis.

Documentation
Quite a bit of documentation has been added to the source code, this has helped to clean up the code as well, as there was still some code that was present for previous debugging.
The source code now also has a cabling guide to assist with wiring the modules.
This includes pin outs for Arduino Pro Mini 5V and Arduino Mega boards (my two test platforms).

Outstanding tasks remaining
* Update the Transmit/Receive pair addresses based on the channel selection (currently to use more than one radio link, these addresses need to be changed per pair in the source code). I have forgotten to do this, more code changes ...

* Publish source code, schematics, bill of materials etc

* Route a final PCB, design a case and mount the hardware, I am 1/2 way through doing this, I need to finish routing the PCB, then test fit the components, solder it up and confirm it works (or fix what doesn't). Then design case to suit the final structure. This is proving to be a bit more painful than I had hoped. Getting my little PCB mill to mill double sided boards is proving to be a bit painful. It also doesn't help that Im learning some new milling software at the same time.

[doggydoc10]

Awesome. Thanks for the update. Can't wait to see the final results


Always at sea;

Dr. Antonio Longo

[JosephWatts]

Thanks for discussing such a useful information here.
I also want to build a wireless system for the range if upto 1Km with a speed of 2Mbps.
Is it possible using the Arduino and the NRF24L01?
Or you people would like to suggest any other module?

circuit board manufacturing (http://www.7pcb.co.uk/PCB-manufacturing/)

[CaptCrash]

Thanks for discussing such a useful information here.
I also want to build a wireless system for the range if upto 1Km with a speed of 2Mbps.
Is it possible using the Arduino and the NRF24L01?
Or you people would like to suggest any other module?

1Km for the NRF24L01 would be quite a challenge, it may be possible with external directional antenna but would be skeptical that the speed of the communications would be maintained.
My tests have all been much shorter than this, initially with the onboard antenna. With these a step up in speed 1/2's the distance.

From what I have read (I have not tried high gain or directional), 1Km+ distances are possible, but not with 2Mb/s only with 250Kb/s using the standard NF24L01+ LA + Antenna. You may be able to achieve better with a high gain directional antenna rather than the standard omnidirectional antenna but this would need to be tested.

Of the things I have read about, the one that looks most interesting is http://hackaday.com/2012/05/18/adding-kilometers-to-a-radio-meant-only-for-meters/ however as is mentioned in the linked page comments, there may be regulatory issues with doing such a thing depending on where you are.
Another choice would be the introduction of a Yagi antenna on each end of the link (details on operation here http://www.marcspages.co.uk/tech/index.htm), however knowing if this would mean you can achieve 1Km at 2Mb/s is beyond my level of knowledge.

[WernerP]

any news on the wireless PAB test?

[CaptCrash]

Its been working well since I last posted.
I had one issue with a microwave oven being used and making it loose connection as the oven was quite noisy (electronically).
I simply moved the microwave further away from the receiver and its been fine since.

There is still a little bit of tidy up on the code but over all it working really well, I should get back to tidying it up and making a better case for both ends so it doesn't get damaged by the damp air.
Overall Im very happy with it.

I have used the same idea to work on another project to see if I can deliver firmware to the various PAB devices I have. I am looking to record the firmware delivery to a single powerbar 6D PAB. This is logged to a microSD card. Then I can attach my recorder to each of the other powerbars and replay the firmware. This way I don't have to go through the silliness of dragging cables to each and every powerbar to do a firmware update.

If I can reverse engineer the process enough, Ill make it so that I can just put firmware on the MicroSD from a computer (shock horror, even a mac) and then send that to the target (hello updates for touch, expansion box and powerboat without most of the day in effort).
At the moment, Im having an issue with talking to the microSD and the CAN bus at the same time, I should really get back onto making it work as my equipment is getting a bit behind in terms of firmware and I would rather spend the effort making the process smoother than to go through another lot of cabling fun.

[CaptCrash]

I noticed the other day that someone was looking for a method of connecting powerbars wirelessly to their profilux controller.
Unfortunately I wasnt able to respond at the time, so Im posting in this thread hoping that the person will notice.

If this is something you are looking for (wireless PAB extension), then let me know.

[doggydoc10]

That would make my life sooooo much easier!
Yes 100%


Sent from my iPhone using Tapatalk

[faltaren]

Does ghl have any plan replacing the pab with wireless?

Skickat från min E6553 via Tapatalk

[CaptCrash]

That would make my life sooooo much easier!
Yes 100%

Sent from my iPhone using Tapatalk

Hi, Would you like a list of the parts needed or do you want units put together?
I am happy to send you a list of parts to purchase and solder together yourself, I can then send you the source code for the arduino's.
Or if you want I can build up a little bundle for you and post it to you in a box.

If you want it made up, let me know how many you want and Ill price up the parts, I expect it will be about AUD$120 including freight world wide per pair assembled and tested.
The parts are around AUD$70 if ordered from eBay or about USD$180 from SparkFun (a more reputable and reliable source). Its about an hour of soldering and then 15-60 minutes to install the software onto the two arduinos depending on if you have the libraries installed on your PC or need to download them.

Let me know what you would prefer

If enough people are interested I can do a batch, work out the costs etc and offer it as a project or complete kit.
This would probably bring the cost down a bit per unit, as there would be less freight etc and I can do another run of boards, so its just plug together rather than soldering each kit up, saving heaps of time and making it more reliable.

Also just to make sure people don't have too high expectations, this has only been tested on my two systems.
They are PIII Ex based with power bar's, touch, expansion boxes etc. One of these systems has a heap of powerbars 6D PAB's (6 I think) and three expansion boxes. So quite a bit of measurement going on, lots of PAB messages and it has been very reliable.
I have not used it with the P4 or the new powerbar's/expansion boxes, so this may need some additional testing and/or changes to the code

I just want to make sure people have a reasonable expectation.

[Julianino]

Hi all,

thread is a bit old but i habe a question to the CAN-Communication.

Does anyone now something about the CAN-ID‘s used for sockets?

I wanted to build a bigger screen to show information about the tank.

Therefore it would be great to get infos about which sockets are on and off.
I used a CAN-Sniffer to see the traffic on the bus but im not quite sure about which id stands for which sockets.

So if anybody has information about this topic would be great to hear something about it.

Special thanks,

Julian

[CaptCrash]

Im about to restart/rebuild this project as I have started a new aquarium after having a break.

Ill be doing an update of the design and making it a bit better using some newer microcontrollers. If anyone is interested Ill publish some progress over the next few weeks/months.

[joehun]

Hi CaptCrash,

it would be nice to get some updates from time to time in this forum.

BR
Joehun

[CaptCrash]

Hi for those that are following this.
I have now had the link for wireless working for about 6 months without any issues (other than some power outages that are unrelated).

My current features for the wifi link are as follows

Two units are required to replace a PAB cable, so that you can convert (bridge) the PAB link to a Wifi network.
The same rules as with a regular PAB network apply, in terms of daisy chained cabling (in and out of devices).
The units can work via an existing Wifi network (existing wifi mode each being a wifi client)
The units can operate their own Wifi network (standalone mode with one unit in AP mode, one unit in client mode).
If the units are operating via an existing network they can be controlled via their web interface (reboot, automatic firmware update, logging on device and central log uploads)

My current setup is as follows


Profilux first PAB connector ->

PAB power bar at marine tank ->
Wifi link (AP mode mode) -> Standalone WIFI link -> Wifi Link (client mode) ->
Expansion Box ->
PAB Powerbar at snake enclosure.


Profilux second PAB connector ->

Wifi link (client mode) -> Connect to existing Wifi Network -> Wifi link (client mode) ->
PAB Powerbar =>
Profilux Touch outside at RO and salt water drums



This lets me do the following with the two Wifi links (only really doing the two this way to test things, will soon convert to both using the existing wWifi).


No cables through the house or outside
Lets me use the same automation for the various locations (marine tank, snake enclosure and water systems)
Provides a platform to add other features in the future


My intended additional features for sometime in the future are

Firmware update tool

Using the device to replay firmware updates to an attached PAB device.
This would stop the need to connect things one at a time back to the aquarium controller
changes would be a battery pack being needed and an interface of some sort (currently web interface to phone)


Home integration addon

Allowing commands/events to be sent on the PAB network initiated from the Wifi link (eg, Im home type events to change lighting patters/colours for better viewing)



If anyone is interested in a pair of these, please let me know.
Im going to do another run of them for a friend, so I would be happy to make a few.
At this stage I expect the cost to be AUD$120 - $140 each, but if I can get to 20 or 30 units, I expect to be more like $50 or $60 each plus shipping.
Im going to order parts in November, delivery will be December/January to me, January/February shipping from me (depending on shipping times etc).
If I can do a batch I expect to be able to bring this down a fair bit, hopefully less than $AUD 100 per unit with shipping.
Happy to take expressions of interest and tighten up the costs once I have an idea on quantities.

Its been a long time coming but its pretty solid and ready to go out in the world.