This is an application note that describes how to get started using Nexmosphere sensors and actuators with experiences managed by Blocks.

The method in this application note is useful if connecting a Nexmosphere controller with a 3.5mm serial connector using a serial network server such as Moxa N-Port. From Blocks version 6.1 it is possible to connect a Nexmosphere with built-in serial to usb controller directly to Pixilab Players USB port. Please consult the manual for more details about serial devices in blocks.

In the examples we use the following hardware:

• Nexmosphere XN-180 Experience controller. This is the "hub" device, with a serial port connected using a 3,5mm jack.
• XT-EF650 Gesture sensor.
• XR-DR1 RFID Pick up sensor.
• XW-L9 X-WAVE animating led strip.
• Moxa NPort 5100 Series - 1 Port Serial Device to TCP/IP Server.
• 3.5mm to D-SUB cable that connects the XN-180 to the Moxa Nport.

Follow this guide to get the Nport configured for use with Blocks Use the following serial communication settings:

• Baudrate 115200
• Flow Control None
• Parity None EOL CR+LF
• Data Bits 8 Protocol ASCII
• Stop Bits 1

You will have to install the Nexmosphere driver on your Blocks server by following this guide

In the editor add the device with the IP address of the N-Port and select the Nexmosphere driver.

It is not possible to hot swap any sensors to the device. If connecting another sensor or removing a sensor the controller must be power cycled before picking up the change. Blocks in turn will poll port 1 to 8 to find out which sensors that is connected and create properties accordingly every time the device is connected. So, if one changes any sensors the driver must be disabled and then enabled before blocks will know of any changes. If a sensors model number on interface 3 is not recognised by the driver a fallback property called iface_3_unknown will be created. Any values received will be passed as a string that may be used for task programming.

Now that the device has been set up you can import this block as a starting point or just create one on your own from scratch. My example has two elements that uses the value from the sensor. Down the bottom there is a text binding that show the current value as text.

I have also applied a scale behaviour to the logotype. The behaviour is bound direct to the sensor’s proximity property. To smooth out the animation a bit i changed the minimum transition rate to 0.3 seconds. To try this, just assign this block to a spot and hold your hand in front of the sensor.

This example block can be downloaded here. In this gesture navigation scenario, I use a simple kiosk application with 3 pages of content stored in a book. I create a couple of blocks buttons that can change page back and forth binding the Go to local block button action targeting the books name followed by a slash and a minus for back.

Repeat the same procedure for the forward button but replace the minus with a plus sign for forward.

Now that the buttons are wired up this can be tested to make sure the pages can be changes by pressing the buttons.

Next trick is to use the gesture sensor to do the button press for us based on the value received from the gesture sensor. To do so we add a press behaviour to the button. The behaviour will only press the button if the iface_2_touch property value is truthy. We use "Sd=LEFT" as a condition for the left button and "Sd=RIGHT" for the right button.

If you want to find out the different values the sensor can send one can create a task that logs the value like in this example.

Perhaps one would want to use a gesture to trigger a task. Let us look at an example task. We trigger the task when iface_2_touch receives a value. As trigger condition we look for the trigger to match "Sd=LEFT". If it does, we just log some information.

In a real scenario the trigger condition would probably be more complex, perhaps we only want to enable this task if a particular piece of content is shown on a screen like in this example:

 trigger === "Sd=LEFT" && Spot.DisplaySpot.block === "Main/Interactive block" 

In this example we have a RFID sensor connected to interface 3 of the controller. We trig a task from the change of tagIsPlaced property and in the task, we log the tagIsPlaced and TagId. Here tag no 3 has been placed and removed again.

It is pretty useful to use a trigger condition to make sure task will only run if the desired tag has been placed.

This example will only run if tag with ID no 4 has been placed.

 Network.Nexmosphere.iface_3_tagId === 4 

The X-WAVE led strips can be useful for user feedback or perhaps light effects.

In this example a LED strip has been connected to interface no 4 of the Nexmosphere controller. In blocks this strip shows up as an unknown device.

If I want to control the LED all I have to do is to send a string command as rawData to the controller like in this example:

 "X004B[250105]" 

Where no 4 in X004B specify the interface that we want to send the command to.

From the X-WAVE API manual i know this means "Set LED output (on interface 4) to 50% intensity with color 1 in 0,5s".

And this little example will briefly change colour whenever a RFID tag has been placed perhaps to provide some user feedback.

Some sensors may have settings that is not persistent between reboots of the Nexmosphere controller. In those cases, you may want to send those settings from a task to the sensor in question and trig that task every time the controllers connected property becomes true.

Some sensors have settings that must be set from Blocks. There is no persistence in the Nexmosphere controller so typically all settings must be set after reboot of the controller. One way of doing this is to run a task that does just that every time the controllers connected property becomes true.

This example will enable "Air Wheel incremental mode" of a gesture sensor. To do that we would send a string command as rawData to the controller.

"X002S[7:2]"

Where 2 in X002S is the interface number. The settings can be found in the API manual

Nexmoshpere uses MIFARE Classic tags and can provide software available for Windows computers that can be used to program tags. This software can be obtained from their support once you got the hardware.

It is also possible to program tags using a mobile phone. I use an Sony phone with Android OS and NFC enabled. Using softare such as MIFARE Classic Tool as in my example it is possible to write any tag ID to your tags.

A valid tag ID has to be between 1-255, 01-FF in hex. In the screenshot below where i read a tag already programmed as tag ID 3, 03 in hex is repeated in all 16 bytes in sector 1 block 0.

If I want to program a new tag with no 255 I would set the application to write tag mode with the following settings and press the write tag button while holding the tag to the mobiles NFC sensor:

This should be the final result from reading the tag with ID 255.