How do you set the channel on a XBee PRO series 2? - embedded

I've got three XBees. 2x PROs and a standard, all series 2s.
I've configured one PRO and one standard to be router/endpoints on channel 0 and PAN 234 (this is the default channel and PAN ID when selecting the "XBP24-B"/"XB24-B" "ZNET2.5 ROUTER/END DEVICE AT" profile (version 1247 for both).
However the one PRO I've set with the "ZNET 2.5 COORDINATOR AT" profile has a channel of E (though if I keep flashing the device with the same profile, this changes from 12-F).
Obviously if the coordinator doesn't have the same channel, nothing will work, but I can't see any way of setting the channel manually..?
The CH setting in X-CTU is read only, and I can see any other UI element to change the channel:
I've even been into the terminal and typed (words in brackets are what the terminal returns):
+++ (OK)
ATCH (E)
ATCH0 (ERROR)
ATCH 0 (ERROR)
ATCH00 (ERROR)
ATCH 00 (ERROR)
ATCH E (ERROR)
ATCHE (ERROR)
I've Googled and Googled to no avail. incredibly frustrating, can anyone help?!
I've had them working previous as a matter of fluke as I kept flashing the hardware until the channel numbers match up, but this is obviously ridiculous!

Channel selection with the XBee ZB (S2, S2B, S2C) series of modules works differently than with the XBee 802.15.4 (S1) modules. Channel selection is automatic with ZB (as opposed to it being manual with the 802.15.4 modules).
You normally never need to manipulate the channel selection parameters with ZB. Modules find each other and associate with each other if they can.
If your modules just can't seem to find each other it usually comes down to a mismatch in the PAN settings (ID), security settings (LK), or network joining permission settings on the coordinator (NJ).
Not a lot of information exists on the web outside of the Digi's XBee ZB OEM manual. For reference sake, channel selection with ZB works like this:
XBee ZB Coordinator is powered up
The XBee ZB Coordinator reads its SC parameter and builds a list of candidate channels to scan
The XBee ZB Coordinator then performs an energy scan on each candidate channel
The XBee ZB Coordinator then chooses the channel with the least amount of energy on it
This procedure aims to pick a channel with the least amount of noise on it be it from microwave ovens, WiFi networks, or anything else that might be transmitting on the 2.4GHz frequency band.
Any router or end devices joining a network with consult their SC parameters first, then they will try and search for networks they can join which match their PAN and security parameters. They will join and stay joined to the first network they can--with some minor exceptions (see the JV and NW parameters, for example).
If you want to force a channel selection you must set the SC parameter to enable only a single channel. The SC parameter is a bitmask1. Each bit set in the mask will enable one additional channel. What's tricky about this parameter is that the first bit (bit 0) is not channel 0, it's channel 11 (0x0B). For ease of use, if you wanted to lock an XBee ZB to a single channel here would be the values:
+---------------+---------------+------------------+-------------------------+
| Channel (Dec) | Channel (Hex) | XBee ZB SC Value | XBee Availability |
+---------------+---------------+------------------+-------------------------+
| 11 | 0xB | 0x1 | All |
| 12 | 0xC | 0x2 | All |
| 13 | 0xD | 0x4 | All |
| 14 | 0xE | 0x8 | All |
| 15 | 0xF | 0x10 | All |
| 16 | 0x10 | 0x20 | All |
| 17 | 0x11 | 0x40 | All |
| 18 | 0x12 | 0x80 | All |
| 19 | 0x13 | 0x100 | All |
| 20 | 0x14 | 0x200 | All |
| 21 | 0x15 | 0x400 | All |
| 22 | 0x16 | 0x800 | All |
| 23 | 0x17 | 0x1000 | All |
| 24 | 0x18 | 0x2000 | All |
| 25 | 0x19 | 0x4000 | S1, S2B, S2C (not S2) |
| 26 | 0x1A | 0x8000 | S1 only |
+---------------+---------------+------------------+-------------------------+

Obviously if the coordinator doesn't
have the same channel, nothing will
work, but I can't see any way of
setting the channel manually..?
I'm not sure if what you say above is right. From http://ftp1.digi.com/support/documentation/90000976_C.pdf (you should look at the correct version for your hardware, though), it looks like the purpose of a coordinator is to automatically determine the channel:
Coordinator Operation
Forming a Network
The coordinator is responsible for
selecting the channel, PAN ID (16-bit
and 64-bit), security policy, and
stack profile for a network. Since a
coordinator is the only device type
that can start a network, each ZigBee
network must have one coordinator.
After the coordinator has started a
network, it can allow new devices to
join the network. It can also route
data packets and communicate with
other devices on the network. To
ensure the coordinator starts on a
good channel and unused PAN ID, the
coordinator performs a series of scans
to discover any RF activity on
different channels (energy scan) and
to discover any nearby operating PANs
(PAN scan). The process for selecting
the channel and PAN ID are described
in the following sections.
Channel Selection
When starting a
network, the coordinator must select a
"good" channel for the network to
operate on. To do this, it performs an
energy scan on multiple channels
(frequencies) to detect energy levels
on each channel. Channels with
excessive energy levels are removed
from its list of potential channels to
start on.
I've actually never used the Digi XBee radios (just some of their other radios), so I don't know much about coordinators. I think that their user interface typically does expose all of the valid commands, so it probably won't work to try sending them manually (as you discovered).
You may find more experts on the Digi forums.

Hmm. strange, keep going over the settings again and finally got it working with 2-way comms?! :S
Setup one a coordinator
Setup other two as router/end devices
Set the Device High (DH) to 0 and the Device Low (DL) to FFFF (this means everything sent from this module should be received by everyone)
Set Negotiate Channel to 1 (Enabled), which means the only time a router/end device can set it's own channel is when it finds a coordinator on the same channel (this clearly wasn't happening in my case)
Everything else was left as default.
Leave coordinator powered on when configuring router/end devices so you can check they pair correctly.
As I said, I've used this configuration before and it just didn't work, so I don't know what kicked it into life this time, but it worked?!

One thing to take into account is that ZigBee channels extend from 11 to 26, zero is not a valid option.
Since that's the case, are you able to try the command ATCH11 ?
If that command succeeds, then perhaps the ATCH command wants a decimal input between 11 and 26?

Related

Using hexagonal architecture in embedded systems

I'm trying to work out how the hexagonal (ports and adapters) architecture might be used in the context of an embedded software system.
if I understand right, the architecture is something like this.
/-----------------\ /-----------------------------\
| | | |
| Application | | Domain |
| | | |
| +----------+ | | +---------+ |
| | +-------------->|interface| | /-------------------\
| +----------+ | | +---------+ | | |
| | | ^ | | Infrastructure |
| | | | | | |
\---------------+-/ | +---+---+ +---------+ | | +----------+ |
| | +---->|interface|<-------------+ | |
Code that allows | +-------+ +---------+ | | +----------+ |
interaction with | | | |
user \--------------------------+--/ \-----------------+-/
Business logic What we (the business)
depend on - persistence,
crypto services etc
Let's take a concrete example of where one of the user interfaces is a touch screen that the main controller talks to over a serial UART. The software sends control commands to draw elements on the screen and the user actions generate text messages.
The bits I see working in this scenario are:
Serial driver
Sends data over the UART
Receives data (an ISR is invoked)
Screen Command builder
Screen Response/Event parser
Business logic such as presenting and responding to menus, widgets etc
The bit I'm struggling with is where these pieces should reside. Intuitively, I feel it's as follows:
Infrastructure - UART driver
Domain - Business logic
Application - Message builder/parser
But this arrangement forces a dependency between Application and Infrastructure where the parser needs to retrieve the data and the builder needs to send the data through the UART.
Bringing the messages builder and parser to Infrastructure or Domain takes the whole user interaction thing away from the Application.
Whichever way I look at it, it seems to violate some aspect of the diagram that I drew above. Any suggestions?

Issue on connecting to the Image Acquisition Device using HALCON

My setup includes a POE camera connected directly to my computer on which I have HDevelop. From the past few days I am running into a problem wherein the first attempt to connect to the camera using HDevelop fails.
When using Connect from the Image Acquisition GUI, I get an error stating "HALCON ERROR. Image acquisition: device cannot be initialized"
When using the open_framegrabber() method from the Program Console, I get a the same error as well, with the addition of the HALCON error code:5312
After I get this error, attempting the connection again, it succeeds. This is the workaround I have at the moment, but its annoying as it keeps repeating quite frequently and I am not sure what is the cause for this issue. I tried pinging my camera from the command prompt which did not show any ping losses. And using the camera from VIMBA viewer I do not get such connection issues.
I know this is not a support site where I should be asking such questions, but if anyone can give me some inputs on solving this, it would be of great help.
Regards,
Sanjay
To solve your question is important to understand the HALCON Framegrabber communication object, I assume that you are coding in HDev code structure.
To create a communication channel with the camera on the proper way, avoiding to reject the connection (due to parameter miss-configuration), you have to specify the camera device ID on the framegrabber creation, and avoid to use default options.
In order to consult, according to your communication protocol, the available devices conected to your board, use:
info_framegrabber('GigEVision2', 'info_boards', Information, ValueList)
where,
The first parameter is the communication protocol and ValueList will throw all the information of the connected devices with a token:param splitted by '|'
i.e
| device:ac4ffc00d5db_SVSVISTEKGmbH_eco274MVGE67 | unique_name:ac4ffc00d5db_SVSVISTEKGmbH_eco274MVGE67 | interface:Esen_ITF_78d004253353c0a80364ffffff00 | producer:Esen | vendor:SVS-VISTEK GmbH | model:eco274MVGE67 | tl_type:GEV | device_ip:192.168.3.101/24 | interface_ip:192.168.3.100/24 | status:busy | device:ac4ffc009cae_SVSVISTEKGmbH_eco274MVGE67 | unique_name:ac4ffc009cae_SVSVISTEKGmbH_eco274MVGE67 | interface:Esen_ITF_78d004253354c0a80264ffffff00 | producer:Esen | vendor:SVS-VISTEK GmbH | model:eco274MVGE67 | tl_type:GEV | device_ip:192.168.2.101/24 | interface_ip:192.168.2.100/24 | status:busy | device:ac4ffc009dc6_SVSVISTEKGmbH_eco274MVGE67 | unique_name:ac4ffc009dc6_SVSVISTEKGmbH_eco274MV
......... and going
In this way you can cast the device ID (device:) automatically, and put this parameter on your framegrabber creation.
open_framegrabber ('GigEVision2', 0, 0, 0, 0, 0, 0, 'default', -1, 'default', -1, 'false', 'here piut the device ID', '', -1, -1, AcqHandle)
At the end you will be able to do a direct connection or create a automatically re-connection routine.
I hope this information helps you.

Mixing fanout and direct exchanges with AMQP

I have two kinds of workers for a same event.
I would like a message be dispatched to only one among some of my workers (like "direct" exchanges). But the other workers should all process the message (like fanout).
It's a bit hard to explain but the idea is here. And maybe the following schema will help you to understand what I would like.
Do you have a solution?
Kind regards,
Ben
If I understand you correctly, you would like to have "type-1" as worker where only a single worker work on an item while "type-2" can be treated as multiple handlers (like log-handlers) where all should accept the event.
If i'm right , then you might be able to chain two queues (exchanges) .
exchange1 - fanout - all the "type-2" (loggers) will wait here so they will all get the event
exchange2 - direct - all your "type-1" will wait here so only one will get the event
the trick - you need to make sure that you have a consumer listening on "exchange1" that will also publish to "exchange2".
your best option is to use routing keys with multiple bindings between your exchange and your queues.
i would recommend either direct or topic exchange for this, but not fanout.
to model your example image above, your configuration would look like this:
| exchange | routing key | queue |
|----------|-------------|---------|
| some.ex | type.1 | queue.1 |
| some.ex | type.1 | queue.2 |
| some.ex | type.1 | queue.3 |
| some.ex | type.2 | queue.4 |
| some.ex | type.2 | queue.5 |
basically, you need to have a routing key per queue and a queue per worker.
you may want to read up a bit more on exchanges, queues and bindings, to get a better understanding of when they would be used. i have a few ebooks that cover this (along with other RMQ usage scenarios) at https://leanpub.com/u/derickbailey

A20 OLinuXino-Micro 4GB from Olimex - understanding GPIOs

i am using a A20 OLinuXino Micro 4GB from Olimex with Debian on SD Card.
I want to use the GPIOs and have some short question about the configuration of the GPIOs. The GPIO-1 connector on the board has pins numbered from 1 to 39. In the manual I have entries like that:
Pin # | Signal name | Processor pin
23 | PG9 | C19
...
39 | LRADC1 | AB22
In the fex file, I find this:
[gpio_para]
gpio_used = 1
gpio_num = 64
...
gpio_pin_10 = port:PG09<0><default><default><default>
How is defined that the processor pin C19 is routed to port PG9?
And port means exactly what?
How is defined that the port PG9 is routed to pin23 of the connector?
Can the gpio_pin_10 designation be chosen arbitrarily?
At the end I would like to use the LRADC1, to sample a signal, but the fex file doesn't have any LRADC1 entry. Why is that?
Maybe somebody could answer may questions in 2 or 3 sentences so it makes sense to the rest of what I read. Thanks!
Please take a look at A20-OLinuXino-MICRO schematics. You can find wiring:
PG09 - C19
PG10 - D18
PG11 - C18
(...)
In mentioned schematics is also section GPIO EXTENSION in which you can find which A20 SoC pin is assigned to which GPIO:
PG09 - 23 GPIO-1
PG10 - 25 GPIO-1
According to Wikipedia:
A GPIO port is a group of GPIO pins (typically 8 GPIO pins) arranged in a group and controlled as a group.
Mapping between physical pin and pin exposed through fex file to operating system is arbitrary. Of course to get correct results you have to assign GPIO ping not. I don't think that fex compiler check anything other then syntax.
In case LRADC0 (again schematics) it us used for buttons (vol +/-, menu, search, ...) and LRADC1 is exposed through GPIO-1 pin 39.

How to compute shared memory anchor address in VxWorks 6.3

I've inherited 3 SBS (now GE Fanuc) C2k single board computers connected over a CompactPCI backplane, and need to get shared memory up and running between them. My understanding is that in previous years, the value for SM_ANCHOR_ADRS was initially "found" by someone, and whenever PMCs were swapped in or out the value for SM_ANCHOR_ADRS was fiddled with until it worked again. This time around, instead of randomly poking memory addresses, I'd like to learn how this value is come about to begin with.
I have noticed in the VxMP manual there's a description of how to compute this address for VME, given a memory map and known offsets. I've tried looking a similar memory map in the C2k user's manual and none exists. (The bits about PCI auto-configuration I saw in the board support package may have something to do with that?)
Also, in case it's useful, relevant bits from the kernel configuration:
Master:
SM_MEM_ADRS NONE
SM_ANCHOR_ADRS (char*)0x4100
SM_ANCHOR_OFFSET 0x4100
SM_INT_TYPE SM_INT_NONE
SM_MAX_WAIT 3000
Slave cards:
SM_MEM_ADRS (SM_ANCHOR_ADRS)
SM_ANCHOR_ADRS (char*)0x84004100 //this is the number that generally gets fiddled with..
SM_ANCHOR_OFFSET 0x4100
SM_INT_TYPE SM_INT_NONE
SM_MAX_WAIT 3000
With this info, how would I go about computing the shared memory anchor address for VxWorks for devices on a CompactPCI backplane?
This is really a function of the PCI bus architecture and its dynamic nature.
The SM_ANCHOR_ADRS represents the shared memory in the PCI address space of the slave card.
The issue is that when you add more cards, the PCI address space can potentially change.
If you use the PCI Auto Configuration you essentially let vxWorks assign the addresses for you. I'm not sure of the assignment order, but I think the address space is allocated in the order devices are detected on the PCI bus.
Let's see if I can illustrate:
PCI Address 3 Devices 4 Devices (Added 1)
0x80000000 (base) +------------------+ +---------------------+
| Host Bridge | | Host Bridge |
| Device (0,0,0) | | Device (0,0,0) |
| 0x01000000 size | | 0x01000000 size |
0x81000000 +------------------+ +---------------------+
| Slave 1 | | Slave 1 |
| Device (0,4,0) | | Device (0,4,0) |
| 0x01000000 size | | 0x01000000 size |
0x82000000 +------------------+ +---------------------+
| Slave 2 | | CPCI Card |
| Device (0,8,0) | | Device (0,6,0) |
| 0x01000000 size | | 0x01000000 size |
0x83000000 +------------------+ +---------------------+
| Slave 2 |
| Device (0,8,0) |
| 0x01000000 size |
+---------------------+
The Device tuple represents (Bus #, Device #, Function #).
The Device # is determined by which slot the PCI card is plugged in. Throw in the possibility of multiple PCI buses and the order in which things get processed can get complicated.
When using the PCI Auto configuration, you specify the base address and size of the PCI memory windows (there are multiple possible PCI memory windows).
The code then goes on the PCI bus and detects the devices. As a device is detected, it tells the PCI system how much memory it needs and the system maps the addresses within the PCI window for that device. In my example, all devices requested 0x01000000 of RAM.
This works well when the PCI configuration is static and doesn't change.
However, as we can see, if we add a new device (the CPCI), then the order of the devices changed, which causes some of the addresses to also change.
PCI Autoconfiguration simplifies the life since you don't have to worry about configuring all the devices ahead of time. They are just discovered.
However, if the configuration is variable, you probably need to configure things manually: i.e. know ahead of time what devices might be present and attempt to configure them. One the upside, you have full control over what address you assign to a given PCI device.
To get back to your question, how do you know the address? If you have access to the vxWorks shell, you can use the pciConfigTopoShow(), which should show you the various PCI devices found and their address spaces.