Murum Lux: IPLogika iPack P401 Modules

2015-05-20 02:30 by Ian

This is a brief recount of my experience using the iPack P401 Module.

Unbox / getting aquainted

This is a brand new product, from what I've been told. There isn't much documentation on it. I see a good number of pins....


The module firmware came running with a webserver and a statically-coded IP address (192.168.1.60). So the first task was to add an IP to my local NIC so that I could talk to it...

ian@iAN-MAiN ~ $ sudo ifconfig enp2s0:0 192.168.1.5 255.255.255.0 up

ian@iAN-MAiN ~ $ ifconfig
enp2s0: flags=4163  mtu 1500                                        
        inet 192.168.0.101  netmask 255.255.255.0  broadcast 192.168.0.255                          
        inet6 fe80::e72b:b3bb:47bb:1725  prefixlen 64  scopeid 0x20                           
        inet6 fe80::6e62:6dff:fe91:f30c  prefixlen 64  scopeid 0x20                           
        ether 6c:62:6d:91:f3:0c  txqueuelen 1000  (Ethernet)                                        
        RX packets 9447723  bytes 10040985653 (9.3 GiB)                                             
        RX errors 0  dropped 614  overruns 0  frame 0                                               
        TX packets 6991309  bytes 2164973356 (2.0 GiB)                                              
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0                                  
                                                                                                    
enp2s0:0: flags=4163  mtu 1500                                      
        inet 192.168.1.5  netmask 255.255.255.0  broadcast 192.168.1.255                            
        ether 6c:62:6d:91:f3:0c  txqueuelen 1000  (Ethernet)

The webserver on the module hosts two basic pages. The first page is a webform with several predefined fields.

The second page is for configuration. The settings are persistent across runtimes, and deal with static vs dynamic IPs, COM port baud rate (to the microcontroller), and options for running a TCP client or a TCP server (both not both).

After setting the baud rate for the iPACK's serial port, I wrote a quick sketch on the Fubarino mini to relay characters between the USB serial port and the iPACK. This example Arduino sketch was helpful for hammering home: Yes... you can treat this part as you would a serial port

Even without running the TCP client/server, I was able to use the webform to send field input back to the microcontroller attached to the serial port.

After playing with this strange new capability, I chose this string format for channelized data from the e-field box to the panel.

At this point, the iPACK module became a tremendous debugging aid, because I could use the webform to simulate data being sent between the LED panel and the e-field box, thereby allowing me to impinge on an existing connection with my own input! This capability saved me many hours of hashing out silly problems, because I could test functionality in isolation on the panel before the capability was written into the Hover driver on the e-field board. Not only that, but in practise, it means that someone on the network can remotely control the panel by sending POST requests to the panel's IP address. This is fantastic. Effortless network integration, and enough built-in stack to build upon.

The TCP server was what really made the modules useful for my problem. The idea here is to act as a transparent serial link between the e-field box and the panel. And in order to do that, the iPACK modules need to be configured to have a server/client relationship.

I opted to use the e-field box as the server, and let the Murum Lux panel be the client. This would allow many devices to connect to the e-field box concurrently.

The panel was coded to look for the TCP server at 192.168.1.61:25000 and keep a connection alive as best it can. I tested this by using netcat to listen for connections. When I powered on the panel with the module connected, netcat gained a connection, and I was able to pass control signals to the panel. Most excellent....

The e-field box was setup to listen for connections on that port. By using a cross-over Ethernet cable, I had a transparent serial link between the e-field box and the panel; emulated over a TCP connection.

Creme...

That I can now do power-over-Ethernet to supply the e-field box is a happy side-effect of taking on the extra complexity. I followed the connection diagram given below. The Fubarino mini can apparently take up to 12v, so it its regulator operating range is the limiting factor, since it is supplying the entire e-field box with 3.3v.


The main panel is putting 5v onto the wire. Might-should add a diode in-line with it so that the gear can be used with a wider variety of PoE parts. From what I understand, people have been known to use voltages as high as 36v in PoE systems, and without more careful treatment of the power conditioning circuits in Murum Lux, interoperability cannot be guaranteed.

It's ashame I couldn't afford to spend more time with the modules. But they served their design purpose with very-little effort, and imparted capability that I didn't know I wanted.

Previous:
Next: