Translate

s2aio

Version 1.8 Just Released


This release corrects a problem encountered when using the SONAR feature.

Xideco Version 0.4.0 Has Been Released


This is a major update!

  • Xideco Router was simplified to use a single ZeroMQ Forwarder.
  • The port_map.py file was simplified to reflect changes in router.
  • Implemented Universal i2c support.
    • Added i2c support to Arduino and Raspberry Pi Bridges.
    • Added i2c support to BeagleBone Black with new file, xibbi2c.py - requires use of Python 2.
    • Add a library class to support ADXL345 Accelerometer.
      • A sample program is provided to create a ZeroMQ data monitor for the ADXL345 class and is described here.
  • Updated FirmataPlus to be consistent with version 2.5.2 of StandardFirmata and is now included with distribution.
    • If you are using a previous version of FirmataPlus it should be replaced with the new version.
    • See Wiki Page for instructions.
  • All modules were modified to allow setting the associated Xideco Router IP address via command line option.

Update On Universal i2c Support

Today I connected an ADXL345 Accelerometer to a BeagleBone Black and another to a Raspberry Pi.

Using a single application running on my Linux PC, I was able to simultaneously receive data updates from both devices.  The Linux PC sends out one universal Xideco i2c command and both devices respond. One message to control multiple devices!!!

In turn, each board forms a universal reply message and publishes the message.  The Linux application subscribes to these messages and parses them on arrival. Reply messages are consistent no matter what type of board is reporting.

Currently the data reported by each board consists of:

  • Board number ID
  • X, Y and Z Axis Raw data
  • X, Y, and Z Axis data expressed in g's
  • X, Y, and Z Axis data expressed as normalized acceleration values.
  • Pitch and Roll

Some of the features supported by the ADXL345 application:

  • Broadcast i2c requests simultaneously to all ADXL345 devices.
    • Each board replies with its own reply message
  • Send i2c requests addressed to a single board.
    •  Only  devices of interest respond, all others stay quiescent.
  • Data requests can be single shot for polling the i2c device.
  • Data requests can be set to report continuosly
    • Continuous reporting can be paused and restarted at any time.
Lots more to test , but this is a very good beginning.  If all goes well, I hope to publish this code within the next couple of weeks.

If you are using pymata-iot and are now seeing these exceptions:

/usr/bin/python3.5 /home/afy/PycharmProjects/pymata_aio/pymata_aio/pymata_iot.py
Traceback (most recent call last):
  File "/home/afy/PycharmProjects/pymata_aio/pymata_aio/pymata_iot.py", line 27, in
    from autobahn.asyncio.websocket import WebSocketServerProtocol, \
  File "/usr/local/lib/python3.5/dist-packages/autobahn/asyncio/__init__.py", line 38, in
    from autobahn.asyncio.wamp import ApplicationSession
  File "/usr/local/lib/python3.5/dist-packages/autobahn/asyncio/wamp.py", line 32, in
    from autobahn.wamp import protocol
  File "/usr/local/lib/python3.5/dist-packages/autobahn/wamp/protocol.py", line 42, in
    from autobahn.wamp.keyring import EncryptedPayload
  File "/usr/local/lib/python3.5/dist-packages/autobahn/wamp/keyring.py", line 64, in
    from pytrie import StringTrie
ImportError: No module named 'pytrie'

Process finished with exit code 1
You will need to manually install pytrie with:
pip install pytrie.

I submitted an issue with Autobahn and hopefully they will fix the issue and install pytrie automatically from a pip install.

PyMata Version 2.12 and pymata-aio Version 2.11 Released



These releases assure that all data sent to Firmata is in 7 bit bytes. There was a  potential for data to be sent as an 8 bit value and these releases assure only 7 bits are transmitted.

Universal i2c Support Took A Major Step Forward Today!

"Write Once, Run Everywhere"


16 February 2016

Using a single application that uses a JSON description of  ADXL345 Accelerometer operations, I successfully communicated with an Arduino, Raspberry Pi and BeagleBone Black to initialize and retrieve the raw X, Y and Z data from the device. 

Each board is able to accept a Xideco set of i2c commands and each board has the capability to translate and execute those commands using its own native i2c library.

What this means is, that on an ongoing basis, new i2c devices will be able to be supported by describing their operations in a single file, and all the boards will be able to support the device without any code changes to the board level (bridge level) code.

Over the next few weeks, I will be further testing and cleaning up the code, and will publish the code as soon as I am satisfied that it is stable. 

Stay tuned!






A New Xideco Router Design

Updates Are In The i2c Branch of Github

14 February 2016

I modified the Xideco router to use the ZeroMQ Forwarder Device. Not only did this simplify the software, but it made it more consistent. All modules connect their publishers and subscribers in the same manner.

Originally I had intended to have two Forwarders, but this actually limited the flexibility of the system. So now, the router consists of a single Forwarder and believe it or not, having a single Forwarder adds system flexibility. Since there is no longer a sense of data flowing explicitly from one type of module or another, any module can subscribe to the topic published by another module. This means that data no longer has to flow to the application for interpretation. This is going to make implementing the i2c features much simpler.

The code is not fully tested, but preliminary tests have not revealed any issues.