Connecting

[splitice]

I'm receiving a timeout exception when connecting to my out of the box XBee S2.

XTCU experiences no issues. Is there a specific firmware this is compatible with? Or something simple I am missing?

[splitice]

The initial timeout is caused by the initial AT command to get the hardware version.

I've checked all the serial parameters match that of XCTU.

[splitice]

Firmware must be API type. Thats the problem on Windows. Still seeing the Timeout exception on Mono on Linux however (armhf/Raspberry PI)

[splitice]

I made it work on mono: https://github.com/splitice/XBee

Of course, all the changes should be conditional to only run on mono. Although they are BC.

[jefffhaynes]

Sweet!  I'll try to take a look this weekend. That hardware timeout has always been an issue. I think it's because the units are still in discovery mode but I don't know how to be sure that they aren't. 

---

I much prefer the sharpest criticism of a single intelligent man to the thoughtless approval of the masses - Johannes Kepler

On Sat, Mar 11, 2017 at 2:11 AM -0500, "Mathew Heard" notifications@github.com wrote:

I made it work on mono: https://github.com/splitice/XBee

Of course, all the changes should be conditional to only run on mono. Although they are BC.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[splitice]

I'll use 'work' in inverted commas for now. I still havent got my two radio's talking.

And I'm still facing timeouts some times on both Windows and very frequently on Linux. I'm still investigating.

The patch I put in my branch was to add a intermediary between the serial port stream, since on mono the serial port stream is pretty poorly implemented.

[jefffhaynes]

I've been considering adding serial dependency injection so I can move the core of the thing to net standard. That way we could just swap out serial implementations. Just haven't gotten around to it...

---

I much prefer the sharpest criticism of a single intelligent man to the thoughtless approval of the masses - Johannes Kepler

On Sat, Mar 11, 2017 at 4:16 AM -0500, "Mathew Heard" notifications@github.com wrote:

I'll use 'work' in inverted commas for now. I still havent got my two radio's talking.

And I'm still facing timeouts some times on both Windows and very frequently on Windows. I'm still investigating.

The patch I put in my branch was to add a intermediary between the serial port stream, since on mono the serial port stream is pretty poorly implemented.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[splitice]

If you have any advice for troubleshooting these issues I'm all ears.

I'm going to try on two windows PCs tomorrow to see how that behaves.

[jefffhaynes]

Yeah I'll take a look and see. Probably not right now since it's 4:30 am and I'm only up because I'm jet lagged :)

---

I much prefer the sharpest criticism of a single intelligent man to the thoughtless approval of the masses - Johannes Kepler

On Sat, Mar 11, 2017 at 4:30 AM -0500, "Mathew Heard" notifications@github.com wrote:

If you have any advice for troubleshooting these issues I'm all ears.

I'm going to try on two windows PCs tomorrow to see how that behaves.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[splitice]

I can confirm that if you attempt to query the XBees too soon after connection to power the query never returns.

I can't seem to get my two XBee S2's to see each other. One is flashed with Endpoint API, the other Coordinator API.

Here is the code I am using?

private static async Task<bool> Run()
        {
            var ports = SerialPort.GetPortNames();
            Console.WriteLine("{0} ports found", ports.Length);
            var controller = await FindAndOpenAsync(ports, 9600);

            if (controller == null)
            {
                return false;
            }
            //controller.Local.SetCoordinatorAsync();

            // setup a simple callback for each time we discover a node
            controller.NodeDiscovered += OnControllerOnNodeDiscovered;

            // now discover the network, which will trigger the NodeDiscovered callback for each node found
            while (true)
            {
                await controller.DiscoverNetworkAsync();
            }

            return true;
        }

OnControllerOnNodeDiscovered never gets a hit on the EP. The coordinator sees the EP.

Have I got to set API mode (i.e End Point / Network Processor) somewhere. Or is there something I am missing? Code is based off the readme.

[splitice]

Goddam it the trick was that the Coordinator is not a node persay, its events come in via the DataReceived event on the controller.

I think some documentation on this would be very helpful.

Now, I'll go back to working on Linux/Mono support.

[jefffhaynes]

Hm, I'm not following. What do you mean by coordinator events?

---

I much prefer the sharpest criticism of a single intelligent man to the thoughtless approval of the masses - Johannes Kepler

On Sat, Mar 11, 2017 at 9:48 PM -0500, "Mathew Heard" notifications@github.com wrote:

Goddam it the trick was that the Coordinator is not a node persay, its events come in via the DataReceived event on the controller.

I think some documentation on this would be very helpful.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[splitice]

If the coordinator hub sends data, (i.e a request for information) the events do not come in via a node, they come in via the DataReceived event on the controller. This is not documented anywhere that I can find. Arguably the first thing anyone with two of these modules wants to try is just that.

One would assume given the README that the Coordinator would be a regular old node (as it is a remote device like any other, just has different capabilities).

[jefffhaynes]

Well if I'm understanding what you're saying, the events should come in on a node as well as on the controller, assuming the node was created using GetNodeAsync. 

---

I much prefer the sharpest criticism of a single intelligent man to the thoughtless approval of the masses - Johannes Kepler

---

From: Mathew Heard notifications@github.com Sent: Saturday, March 11, 2017 9:53 PM Subject: Re: [jefffhaynes/XBee] Connecting (#20) To: jefffhaynes/XBee xbee@noreply.github.com Cc: Comment comment@noreply.github.com, Jeff Haynes feedyurhed@gmail.com

If the coordinator hub sends data, (i.e a request for information) the events do not come in via a node, they come in via the DataReceived event on the controller. This is not documented anywhere that I can find. Arguably the first thing anyone with two of these modules wants to try is just that.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[splitice]

I'd be happy if that node was available as .Coordinator, or if the current behaviour was documented.

I somewhat assumed I'd have to call discover network to find the coordinator, then the coordinator would be a discovered node.

[splitice]

I ended up switching the serial port implementation to SerialPortStream which seems to work much better than the .NET implementation.

Now I'm getting issues with the events triggering. I'm seeing the read calls with the data I am sending (a co-worker joke, "Bing Sucks").

[pid  3016] read(3, "~", 1048547)       = 1
[pid  3016] read(3, "\0\26", 1048546)   = 2
[pid  3016] read(3, "\220", 1048544)    = 1
[pid  3016] read(3, "\0\23", 1048543)   = 2
[pid  3016] read(3, "\242", 1048541)    = 1
[pid  3016] read(3, "\0A", 1048540)     = 2
[pid  3016] read(3, "N", 1048538)       = 1
[pid  3016] read(3, "N", 1048537)       = 1
[pid  3016] read(3, "b\0", 1048536)     = 2
[pid  3016] read(3, "\0", 1048534)      = 1
[pid  3016] read(3, "\1Bi", 1048533)    = 3
[pid  3016] read(3, "n", 1048530)       = 1
[pid  3016] read(3, "g ", 1048529)      = 2
[pid  3016] read(3, "S", 1048527)       = 1
[pid  3016] read(3, "u", 1048526)       = 1
[pid  3016] read(3, "ck", 1048525)      = 2
[pid  3016] read(3, "s", 1048523)       = 1
[pid  3016] read(3, "\321", 1048522)    = 1
[pid  3014] read(6, "\316Ju\335", 4)    = 4
[pid  3010] read(6, "\224WG\267", 4)    = 4
[pid  3014] read(6, "'\305\310\305", 4) = 4
[pid  3010] read(6, "\247F8\363", 4)    = 4
[pid  3011] read(6, "t\243\362\310", 4) = 4

[splitice]

Ok, that was a mono bug.

Looks like all that is needed is an alternate Serial port interface. Perhaps Dependency Injected.

[jefffhaynes]

The coordinator is the device attached to your machine or whatever is running this code. There is no concept of discovering the coordinator in XBees. But yeah, the documentation needs work.

So at this point at what specifically should I be looking? Dependency injection for the serial device or is there something else going on?

[splitice]

Discovering the coordinator is discovering the network. But yes it does seem like the xbees hide all this. It would be handy if it was controllable :(

Currently I have me Xbee (coordinator) and Xbee (EP) talking. Now I just need to get my Xbee (EP) talking to a TI CC2531 based hub. I'm seriously hoping Digi fixed their standards compliant break (http://e2e.ti.com/support/wireless_connectivity/zigbee_6lowpan_802-15-4_mac/f/158/t/217166)....

DI would probably be the best approach, otherwise just pick a good implementation? SerialportStream is working for me on WIndows and Linux (it uses a custom native .so on linux)

[jefffhaynes]

If you want to take a look, I have a "core" branch in beta that is based on .NET Standard. You might have more luck with it. Annoyingly, there appear to be UART timing issues in the RPi3, at least for Windows IoT Core (sounds like there is a workaround for linux on the Pi3). The core branch changes to a DI model that might be easier to port to various hardwares.

[jefffhaynes]

the 5.0+ library includes complete UWP support. Let me know if you have any issues with it.