Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Nick_W

Pages: 1 [2] 3 4
16
mc-Module / Maximum Length of a String?
« on: January 16, 2017, 04:43:23 pm »
Is there a maximum length of a string?

I ask, because I have a json object, which I am publishing via MQTT, and I'm getting a run time error "arguments too long", which is where I convert the json to a string (prior to ListofByte).

Depending on how long the strings in the json are, I get the error, or not. The magic number seems to be around 280 characters.

I'm working around it by splitting the strings into two json objects, and publishing both of them (which works).

What are the limitations?

Thanks,

17
mc-Module / Lots of new things posted
« on: January 16, 2017, 01:08:23 pm »
Checkout my github https://github.com/NickWaterton/mcScript

Lots of new things,

New Time library, provides multiple instances of Device.GetTimeSpan(), in millis and micros, Unix style GetTimeStamp in multiple formats, GetUptimeString() to get uptime in human readable format, plus further enhancements to follow.

New 110 Module DoorSensor version (now uses Time Library)
New 120 module accelerometer library update.
New Demo 205 test program.

New python module mqtt logging program.

Hopefully I'll get a few more updates in over the next few days.

Hope the new versions work for you!

For more info see the bottom of this post http://mcthings.createaforum.com/mc-demo205/tilting-trigger-on-the-accelerometer/.

18
mc-Gateway / Odd behavior of Gateway after last F/W update
« on: January 13, 2017, 02:38:21 pm »
I would like to report some strange thing I am seeing after the last couple of F/W updates:

First, after the last upgrade, my previous problems connecting to WiFI have disappeared! My gateway is now connecting to WiFi properly again. I think this confirms that something in one of the recent upgrades broke WiFi - probably something to do with the gateway registry, as that was erased in the last upgrade.

After reconnecting to each module, mqtt data started to flow again.

Now, since I have implemented my timestamping system, I can see the delays from module to gateway to broker to me. Usually in the range of 3 seconds (but some at 140s), which could just be clock synchronization offset (I'm looking at delivery variation, not absolute values). This compares the timestamp from my server (from NTP) with the module timestamp (from the onboard RTC, set via the gateway).

However, from time to time, there will be a period when no mqtt data arrives on schedule, but then later, 2 or more messages arrive at the same time. I can see from the timestamps that they were sent on time correctly, but the gateway seems to be caching the messages, then delivers 2 or sometimes 3 messages all at once.

See this example output from my logging program: The timestamp on the left is from my server receiving the data from the broker (running on the server), the decoded timestamp is from the module.

Code: [Select]
[I 2017-01-13 15:22:37,548] MCThings/000111BC/BatteryVoltage : 3596.0
[I 2017-01-13 15:22:37,548] MCThings/000111BC/Rssi           : -79
[I 2017-01-13 15:22:38,917] MCThings/000111BC/Data           : Decoded timestamp: 2017-01-13 15:19:48.727000
                                                               WARNING: Publishing Delay of : 170.191 s
                                                               {
                                                                 "time": "1484338788727",
                                                                 "Uptime": 73684,
                                                                 "UptimeString": "0:20:28:4",
                                                                 "BatteryVoltage": 3596,
                                                                 "Temperature": 23.125,
                                                                 "LowBattery": false
                                                               }
[I 2017-01-13 15:22:39,048] MCThings/000111BC/Data           : Decoded timestamp: 2017-01-13 15:20:18.776000
                                                               WARNING: Publishing Delay of : 140.273 s
                                                               {
                                                                 "time": "1484338818776",
                                                                 "Uptime": 73714,
                                                                 "UptimeString": "0:20:28:34",
                                                                 "BatteryVoltage": 3596,
                                                                 "Temperature": 23.125,
                                                                 "LowBattery": false
                                                               }
[I 2017-01-13 15:23:07,973] MCThings/000111BC/LowBattery     : 0.0
[I 2017-01-13 15:23:07,974] MCThings/000111BC/Rssi           : -79
[I 2017-01-13 15:23:13,294] MCThings/000111BC/LowBattery     : 0.0
[I 2017-01-13 15:23:13,294] MCThings/000111BC/Rssi           : -79
[I 2017-01-13 15:23:23,293] MCThings/000111BC/LowBattery     : 0.0
[I 2017-01-13 15:23:23,293] MCThings/000111BC/Rssi           : -79
[I 2017-01-13 15:23:37,898] MCThings/000111BC/LowBattery     : 0.0
[I 2017-01-13 15:23:37,898] MCThings/000111BC/Rssi           : -79
[I 2017-01-13 15:23:40,309] MCThings/000111BC/LowBattery     : 0.0
[I 2017-01-13 15:23:40,309] MCThings/000111BC/Rssi           : -79
[I 2017-01-13 15:23:41,114] MCThings/000111BC/Data           : Decoded timestamp: 2017-01-13 15:20:48.825000
                                                               WARNING: Publishing Delay of : 172.290 s
                                                               {
                                                                 "time": "1484338848825",
                                                                 "Uptime": 73744,
                                                                 "UptimeString": "0:20:29:4",
                                                                 "BatteryVoltage": 3596,
                                                                 "Temperature": 23.125,
                                                                 "LowBattery": false
                                                               }
[I 2017-01-13 15:23:41,243] MCThings/000111BC/Data           : Decoded timestamp: 2017-01-13 15:21:18.874000
                                                               WARNING: Publishing Delay of : 142.369 s
                                                               {
                                                                 "time": "1484338878874",
                                                                 "Uptime": 73774,
                                                                 "UptimeString": "0:20:29:34",
                                                                 "BatteryVoltage": 3596,
                                                                 "Temperature": 23.125,
                                                                 "LowBattery": false
                                                               }
[I 2017-01-13 15:24:07,943] MCThings/000111BC/BatteryVoltage : 3596.0
[I 2017-01-13 15:24:07,944] MCThings/000111BC/Rssi           : -79
[I 2017-01-13 15:24:09,936] MCThings/000111BC/Data           : Decoded timestamp: 2017-01-13 15:21:48.923000
                                                               WARNING: Publishing Delay of : 141.013 s
                                                               {
                                                                 "time": "1484338908923",
                                                                 "Uptime": 73804,
                                                                 "UptimeString": "0:20:30:4",
                                                                 "BatteryVoltage": 3596,
                                                                 "Temperature": 23.125,
                                                                 "LowBattery": false
                                                               }
[I 2017-01-13 15:24:23,292] MCThings/000111BC/BatteryVoltage : 3596.0
[I 2017-01-13 15:24:23,292] MCThings/000111BC/Rssi           : -77

This is from a module set to publish json data every 30 seconds (the other numbers are decoded beacons). I'm assuming that the 140s baseline is just clock offset (but another module gives a delay of 3 seconds - they were both uploaded today - so why the difference?).

Anyway, as you can see, the internal timestamps show that they are indeed sent 30s apart, but they are received in groups of 1,2 or sometimes 3.

My gateway is back in it's central location, and QoS is set to default (QoS.AtMostOnce I think.)

Is my gateway still messed up? it didn't use to do this before. All my modules are doing this, not just one. The only ones that seem to be OK, are the ones not sending json (but they don't have timestamps, so it's hard to tell).

Some modules mostly report correctly, with occasional "make up" publishing, others mostly publish in groups. They are all the same distance (with rssi in the -70 range) from the gateway.

I do seem to be missing some beacons also. This sort of thing was definitely not happening before the latest upgrades. For example, my door sensor would report door open/closed within 0.2 seconds of my other door sensors reporting. Now, I get a sequence of door open/close events minutes after to door has opened/closed.

This is a log from my door sensor (which has not updated it's RTC - not sure why...):

Code: [Select]
[I 2017-01-13 15:49:06,687] subscribing to MCThings/000111C2/#
[I 2017-01-13 15:49:08,820] MCThings/000111C2/Door : 0.0
[I 2017-01-13 15:49:08,820] MCThings/000111C2/Rssi : -72
[I 2017-01-13 15:49:10,075] MCThings/000111C2/Data : Decoded timestamp: 1999-12-31 17:20:07.264000
                                                     Date/time not updated on module
                                                     {
                                                       "time": "946678807264",
                                                       "Uptime": 8407,
                                                       "UptimeString": "0:2:20:7",
                                                       "BatteryVoltage": 2819,
                                                       "Temperature": 14.875,
                                                       "Door": false,
                                                       "KnockEnable": true,
                                                       "PublishEnable": true
                                                     }
[I 2017-01-13 15:49:20,132] MCThings/000111C2/Door : 1.0
[I 2017-01-13 15:49:20,132] MCThings/000111C2/Rssi : -81
[I 2017-01-13 15:49:23,778] MCThings/000111C2/Door : 0.0
[I 2017-01-13 15:49:23,778] MCThings/000111C2/Rssi : -72
[I 2017-01-13 15:50:01,183] MCThings/000111C2/Door : 0.0
[I 2017-01-13 15:50:01,183] MCThings/000111C2/Rssi : -72
[I 2017-01-13 15:50:08,991] MCThings/000111C2/Uptime : 8467.0
[I 2017-01-13 15:50:08,992] MCThings/000111C2/Rssi   : -72
[I 2017-01-13 15:50:09,898] MCThings/000111C2/Data   : Decoded timestamp: 1999-12-31 17:20:18.144000
                                                       Date/time not updated on module
                                                       {
                                                         "time": "946678818144",
                                                         "Doorknock": true
                                                       }
[I 2017-01-13 15:50:10,019] MCThings/000111C2/Data   : Decoded timestamp: 1999-12-31 17:20:18.259000
                                                       Date/time not updated on module
                                                       {
                                                         "time": "946678818259",
                                                         "Door": true
                                                       }
[I 2017-01-13 15:50:10,144] MCThings/000111C2/Data   : Decoded timestamp: 1999-12-31 17:20:20.850000
                                                       Date/time not updated on module
                                                       {
                                                         "time": "946678820850",
                                                         "Door": false
                                                       }
[I 2017-01-13 15:50:10,327] MCThings/000111C2/Data   : Decoded timestamp: 1999-12-31 17:21:07.311000
                                                       Date/time not updated on module
                                                       {
                                                         "time": "946678867311",
                                                         "Uptime": 8467,
                                                         "UptimeString": "0:2:21:7",
                                                         "BatteryVoltage": 2819,
                                                         "Temperature": 14.9375,
                                                         "Door": false,
                                                         "KnockEnable": true,
                                                         "PublishEnable": true
                                                       }

Note the "[I 2017-01-13 15:49:20,132] MCThings/000111C2/Door : 1.0" this is a beacon reporting the door open, then "[I 2017-01-13 15:49:23,778] MCThings/000111C2/Door : 0.0" (0.0 is closed). So the door opened at 15:49:20,132 and closed 3.5 seconds later. The MQTT doesn't show up until "[I 2017-01-13 15:50:10,019]" ie 50 seconds later, but the internal timestamps show the same 3.5 seconds difference, so they were sent correctly, at the correct time, but all arrive at once.

This is NOT what used to happen before the latest upgrades, and obviously makes a door sensor useless...

Any idea's what is going on? this is messing with my real-time data collection.

19
mc-Module / MQTT QoS How Does it Work?
« on: January 12, 2017, 10:06:40 am »
Can anyone explain how the MQTT QoS setting works?

The reason I ask is that I'm not sure if this is controlling the connection between the module and the gateway, or the gateway and the MQTT server.

My gateway is not connecting to WiFi properly (after the last firmware upgrade - but this may be co-incidence), so I have connected it via Ethernet to my switch, which is in the basement. Now, some modules that are far away are only communicating sporadically.

Beacons mostly get through, but most (not all) MQTT messages are missed. I was wondering if changing the QoS setting would help. ie, does the module resend the MQTT message, if it does not get acknowledgment from the gateway (if QoS was set to QoS.AtLeastOnce), or does the module just "fire and forget", and the QoS setting is more to do with the gateway caching the message until it can confirm that the server has received it (in which case this is not of much use to me as it's hard wired).

Not sure why beacons would get through, but not mqtt messages - other than the fact that beacons are small, and mqtt messages are long...

Everything seems to work OK with the gateway centrally located, but WiFi either won't connect, or drops out (when it does connect) after a few hours (and doesn't reconnect).

Is there a warranty on the gateways? I've had it less than a year...

20
mc-Module / New firmware - so far so good
« on: January 06, 2017, 03:31:27 pm »
Just to let you know, up to 3 days 6 hours with no resets, and still publishing on 110 and 120 modules!

Jury is still out on battery life for the 120 module (at 2.78 V after 3 days from fresh battery, publishing every 10 seconds.)

21
mc-Studio / Having problems with V 905
« on: November 18, 2016, 08:00:02 am »
Can't get V905 to start up reliably. When it does start (takes some doing), it seems to mess up my library code - repeats lines, complains of errors then. Haven't changed the code, but is causing real problems.

22
mc-Module / DateTime issues
« on: November 08, 2016, 07:54:33 am »
I was constructing an uptime string recently, and found that DateTime.AddSeconds() does not seem to work. It doesn't cause an error, it just doesn't add anything to the DateTime object.

Also we still don't know what the format strings are for DateTime.toString().

Just to add to your list of ToDo's.

Regards,

23
mc-Innovations / Front Door Sensor via MQTT
« on: November 04, 2016, 03:56:12 pm »
I know, this sounds like the project shown in the example video - door open/close sensor, well it is, but on steroids!

This project addresses several needs. As you may find, any home automation system needs a good way to detect the status of doors/windows, especially the front door. This is needed for:

  • Security (obvious I guess)
  • Automation of door locking
  • Turning Lights on/off

Plus many more. The problem I found is that if you want wireless sensors (and who doesn't), there are really only two choices, Zwave and Insteon. Most of these consist of large ugly boxes, with magnets. Fortunately, you can get hidden sensors as well (some very weird ones - check this out http://darwinsden.com/strips-zwave-door-window-sensor-review/).

This is the best Zwave one I have found: http://aeotec.com/hidden-z-wave-door-sensor, and this is the best insteon one I have found: http://www.insteon.com/hidden-door-sensor/

The problem with all these sensors is that they only report when the status of the door changes (to save battery). You can't get an absolute value from them, just a change. The battery reporting is a bit digital as well - ie 100%, 100%, 100% - nothing. So when your door sensor battery dies, you have no idea what the door status is (especially if you are on the road as I tend to be), and that messes up all your other dependent routines (door locking/unlocking for example).

So my solution to date has been to have two sensors, the main Zwave one (which is ultra reliable until the battery dies), and a backup one (insteon) which is not as reliable - you would not believe how fast the front door opens and closes when my kids come and go, and the insteon sometimes misses a transition. The missed transition can be an issue, as now you have one sensor saying the door is closed, and one saying it is open. I believe the Zwave (reliable) one, but when the battery dies, I have to switch to the unreliable one. Not the best situation for the front door (especially when I use this to auto-lock the door with a yale zwave lock). I need a third sensor, that meets the following criteria:

  • Small (no large boxes!)
  • long battery life
  • reliable
  • can report status, not just events
  • Not Zwave or Insteon

Solution:
mcModule 110! Bonus, with the accelerometer, you can also detect people knocking at the front door (I have a door bell, but lots of people are baffled by it - it's an August smart door bell). They knock on the door, and say "I couldn't find the door bell" - I say "it's the thing with the button with a picture of a bell on it next to the door".

NOTE: the code for this is written for the 110 module, it will not work for the 120 until the accelerometer library for the 120 module is working. You could use it without the door knock feature though.

The module is used as is, no wiring or anything. I attached it with velcro to the top left of the door. The module goes on the door, and a small magnet attaches to the frame (see the pictures).

The module reports battery, door status (open/closed), temperature (why not), and uptime every 30 seconds in turn. It also reports a double tap on the door as a door knock, with some lock out timing to prevent door opening/closing etc from setting off the knock sensor.

As usual (for me) this reports through my openhab set up, and pushes alerts to my phone when a door knock is detected.

With this added to the door, I now have an absolute method of telling if the door is open or closed, and with three sensors (using different technologies for redundancy), I can use 2 out of 3 voting to decide what is the actual door status, and best guess if one sensor has a dead battery.

We will see what the battery life is like.

code is here: https://github.com/NickWaterton/mcScript/tree/master/projects/DoorSensor

This is what the output of my front door log looks like:

Code: [Select]
2016-11-04 15:25:15.758 [INFO ] - Front Door OPEN (ZWave Sensor)
2016-11-04 15:25:15.849 [INFO ] - Front Door OPENED - Master Sensor: Zwave
2016-11-04 15:25:16.116 [INFO ] - Front Door OPEN (Insteon Sensor)
2016-11-04 15:25:16.220 [DEBUG] - Setting Front Door Indicator (153) to hallway_HSM200_setcolour Mode: 8
2016-11-04 15:25:16.435 [DEBUG] - HSM200 Indicator Changed to value: 8 (Yellow)
2016-11-04 15:25:16.671 [DEBUG] - Setting Front Door Indicator (153) Mode to: Fast BLUE (door open)
2016-11-04 15:25:16.818 [INFO ] - Front Door OPEN (mcThings Sensor)
2016-11-04 15:25:24.377 [INFO ] - Front Door CLOSED (ZWave Sensor)
2016-11-04 15:25:24.414 [INFO ] - Front Door CLOSED - Master Sensor: Zwave
2016-11-04 15:25:24.415 [DEBUG] - Setting Front Door Indicator (153) to hallway_HSM200_setcolour Mode: 5
2016-11-04 15:25:24.417 [DEBUG] - HSM200 Indicator Changed to value: 5 (Blue)
2016-11-04 15:25:24.418 [INFO ] - AutoRelock: autolock timer (FrontDoor) reset by: Door Close Auto Lock for 5 more minutes
2016-11-04 15:25:24.420 [DEBUG] - Setting Front Door Indicator (153) Mode to: Tail Yellow (lock pending)
2016-11-04 15:25:24.700 [INFO ] - Front Door CLOSED (Insteon Sensor)
2016-11-04 15:25:24.968 [INFO ] - Front Door CLOSED (mcThings Sensor)
2016-11-04 15:30:24.423 [INFO ] - AutoRelock: Front Door Locked by: Door Close Auto Lock
2016-11-04 15:30:24.427 [INFO ] - Front Door LOCK command received
2016-11-04 15:30:24.432 [DEBUG] - Setting Front Door Indicator (153) Mode to: Tail RED (locking)
2016-11-04 15:30:33.380 [DEBUG] - Front Door Lock Status updated to: CLOSED
2016-11-04 15:30:33.380 [INFO ] - Delay between Front Door Lock receiving command and CONFIRMED response: 8.958s
2016-11-04 15:30:33.418 [INFO ] - Door Lock confirmed recipt of Lock command
2016-11-04 15:30:33.418 [DEBUG] - Setting Front Door Indicator (153) to hallway_HSM200_setcolour Mode: 4
2016-11-04 15:30:33.420 [DEBUG] - HSM200 Indicator Changed to value: 4 (Green)
2016-11-04 15:30:33.424 [DEBUG] - Setting Front Door Indicator (153) Mode to: Slow RED (locked)
2016-11-04 15:30:33.917 [INFO ] - Front Door is CONFIRMED LOCKED
2016-11-04 15:30:53.308 [INFO ] - Door Lock Battery level: 66%
2016-11-04 15:30:53.368 [INFO ] - Front Door command status: SUCCESS
2016-11-04 15:32:23.915 [INFO ] - Door Knock Detected at: 2016-11-04 15:32:23

All I need now is a nice white box to put the module in - hint hint...

24
mc-Module / Getting reboots during interrupts
« on: November 03, 2016, 09:12:31 pm »
Hi,

I'm using acceleratorInt1 to read "click" events (110 module). It's set quite sensitively, so tapping the module produces a lot of interrupts (I'm using the green led to show the event being triggered).

If I tap the module 20-30 times, the module reboots. I've put a 300ms delay in the interrupt routine, to slow the events Down, which seems to help, but this could be that it just takes longer to get 20-30 taps!

I think the module is running out of RAM (no run time errors in debugging, just "lost communications" when the module reboots).

Any suggestions, or is there a limit to how many times an interrupt can be triggered in a short time period?

Thanks,

25
mc-Innovations / mcThings Battery Monitor via MQTT
« on: November 01, 2016, 05:03:16 pm »
This sounds like a simple project, but has some interesting features. Took me about 1 hour to hook up, and another hour hacking code (and another hour to download to the module - kidding! not really).

Background:

I have a Z-Wave multi-sensor (Aeon labs MS6) used to control a light in a stairwell using the motion detection feature. Originally this was battery powered, but the batteries only last a month or two (not the years they are supposed to). As the sensor is hard to get to, I converted the sensor to Mains Power (the sensors can run off 5V DC) to avoid the battery changing issue.

However, there is no power conveniently by the light, other than the (switched) power going to the bulb itself (it's actually an LED bulb, but that doesn't matter). As a solution, I wired a small 5V supply into the bulb socket (a 2A USB charger), then connected this to an adafruit PowerBoost 1000c. This takes 5V in, and charges a LiPo battery. When power is lost (the light switches off), the LiPo supply's power to the 5V out, ensuring uninterrupted 5V power out for the motion sensor.

See here https://learn.adafruit.com/adafruit-powerboost-1000c-load-share-usb-charge-boost/overview

This works well, as long as the light is on long enough for the LiPo to charge more than the sensor draws over time.

I found that after a week or two, the LiPo would become discharged (I'm using a 4,400 mAh LiPo). Turning the light on for a few hours would recharge it, but this was a nuisance. I tried an automated solution using best guesses as to charge/discharge rates, sensing when the light was on etc, but this doesn't work well. I needed real time monitoring of the LiPo battery state, in a small footprint, that doesn't draw too much power (ie discharge the LiPo even faster), and can report periodically, without wires.

Solution:
mcThings 110 module. This can monitor the battery voltage, read the status of the "Low Battery" pin, measure the temperature of the LiPo, and report every 30 seconds via MQTT over Low Power radio. Impact on battery life should be minimal.

Challenges:

The nominal LiPo voltage is 3.7V, but this can go as high as 4.2V when charging. This is higher than the 3.6V maximum for an mcThings module. The "LBO" pin (low battery) is normally connected to the battery (via an LED), and is pulled low when the battery voltage drops below the preset limit (3.2V), so this is also above the 3.6V limit.

The solution was to wire a small diode (500mA rectifier diode) in line with the power input, and a reverse bias (blocking) diode from the module to the LBO pin on the PowerBoost 1000c.

With the modules green LED on (to provide a small continuous load), the in line diode drops the LiPo voltage to 3.6V when charging, so just within our limit.

The module is wired PowerBoost 1000c VBAT via a diode to module pin 12, GND to pin 4 and LBO via reverse bias diode to module pin 8

The module is then cable tied to the LiPo battery (so that the temperature sensor reads close to the temperature of the battery), and everything is hidden in the ceiling (see the pictures - I didn't take any of the wiring - but if I take it down, I'll try to add some).

The code is on my github, under "projects" "BatteryMonitor" here: https://github.com/NickWaterton/mcScript/tree/master/projects/BatteryMonitor

The MQTT library code contains a lot of "stuff" to ensure the module keeps publishing, and also puts the data in the module beacons (which you can decode using beacon_decode.py from my site), so that you get data even if the module stops publishing.

The "diode to drop the voltage" is a bit of a hack, and if I'm not happy with it, I may replace it with a small voltage regulator, but then I'd have to put in a voltage divider to another pin to monitor the battery voltage, so more work, and this seems to work fine for what it is.

The MQTT data gets fed to my Openhab set up (which is what I use for most things) , with some rules to turn on the light when the battery gets low, and some monitoring to make sure we are receiving data, and the temperature is within range etc.

I may update this when I have more data, as this just went in, and may need some fine tuning  ;D.

OK, modified the code slightly, and added some pictures as I had to take the module out of the ceiling to update it.

26
mc-Module / Modules stop publishing
« on: October 31, 2016, 07:56:33 pm »
I have the latest firmware running on a couple of 110 modules. One of the bug fixes is
Quote
Receiving pub/sub deliveries under quick success could cause the device to not receive further deliveries.

Just to report this is not fixed, it still happens. If you publish 3-4 items in a short period of time, the module stops publishing, The module will start publishing again, eventually.

I have put together a complicated queueing mechanism that slows publishing down to once per 3 seconds (no matter how fast you publish). This seems to work, no more missed messages. Hampered a bit by the bugs in the ListOfObjects functions, but working.

Be nice if this could be sorted out, publishing reliably is fundamental to most things. BTW, does the QoS settings work? I don't see any difference when I set them.

Thanks,

27
mc-Module / Indexers How do they work?
« on: October 22, 2016, 08:56:24 pm »
I'm trying to understand Indexers, as they seem to do what I want, but I am having a hard time understanding them.

These are described in section 8.1.4 Indexers page 56 and 57 of the manual. The example is only partial code however, and with multiple references to "lists" and "foo", but no example of the class FooList that "operates as a list of Foo classes" (sorry that statement just disappears up its own foo list), I cannot figure it out.

Does anyone have a full example of how Indexers work? Preferably one without foo or bar, so that I can understand them?

I'm trying to create a c like structure, that I can iterate on in a for loop, The structure would have elements of different types. I could use a class possibly as a structure, and was thinking to use Indexers to index it.

Maybe I'm going about this wrong.

Any suggestions/examples?

Thanks.

28
mc-Module / Module (110) stops publishing
« on: October 20, 2016, 11:12:42 pm »
I keep running into a problem where a module that has been publishing fine suddenly stops publishing. Beacons continue, and my program is still running, but nothing is published anymore.

Power cycle, and off we go again. This happens usually after a few minutes, and seems to be related to how frequently I publish. The more often you publish, the faster this happens.

If you publish once per second, publishing quickly stops. Once every 10 seconds, and it can be minutes, or indeed work for ever (or until the module spontaneously reboots).

Is there a fix for this? It's really messing about with my programming.

Thanks.

29
mc-Module / Module 120 accelerometer communications
« on: October 01, 2016, 07:50:39 pm »
So, back from the road, and my 120 modules have arrived!

I set them up, with the hope of making some progress on a library for the new accelerometer.

First, a lot of trouble connecting and downloading code (even with the latest firmware, mcStudio etc.). The module has to be really close to the Gateway for it to download reliably. I mean inches away.

But, figured that out.

Now, can't talk to the accelerometer. Some odd behavior, if I set the I2C speed to 400kHz, the whole module hangs (have to "delete code" to recover). Set to 250kHz, it seems OK. I2C address set to 0x19.

So trying at 250kHz, first step is to read the WHO_AM_I register (either 0x0f or 0xaf - depending on register auto increment or not), this should yield 0x33. No matter what I try, I read 0. And it actually reads 0, not just "nothing". Trying to read other registers also yields 0.

I have checked the I2C data sequence, and it seems to be the same as the 110 module accelerometer (which works).

Does anyone have some example code using the new accelerometer (just who_am_i would be fine)?
I'm not sure if this is a bug (the hang at 400kHz is worrying), or something I'm missing.

Any help with the 120 module accelerometer would be appreciated.

30
mc-Product General / Considerations on Wireless Range
« on: September 09, 2016, 12:38:48 pm »
I have been looking at the range of the modules.

I was having problems connecting from the first floor of my house to the ground floor. Knowing that Low Power 2.4 GHz has trouble passing through obstacles, I was thinking this was simple attenuation.

Looking at the antenna design further though, I believe there are some fundamental antenna design considerations to take into account.

The module antenna seems to be 1/4 wave monopole (via a QFN balun) of the inverted F design.

I'm not sure exactly where the ground plane for the antenna is (I can't see it, but it has to be there).

So, things to take into account to get the best range from the module.

1) surroundings.
By this I mean things close to the antenna. Material close to the antenna will effect it's impedance, and hence it's matching (and thus reflected power). This includes plastic, wood, people, and metals. Antennas work best for the environment they are matched to (at design time). I don't know if the antenna was designed for a free air environment, but placing the module on a surface or in an enclosure can cause problems.

One reason I believe that I have some problems with range to a door sensor, is that it is attached to a door! Worse, the door is a steel door. Short of attaching a wire antenna, there is not much I can do about this though.

2) Ground Plane
A monopole antenna needs a good ground plane, but it must be a minimum distance from that ground plane. A steel door for instance a few mm from the antenna will not be good. I also noticed the coin cell slightly overlaps the antenna area. moving the coin cell may help improve range, or using the module with a separate supply (to remove the coin cell completely) may help. Avoid placing the module directly on a surface (close to the antenna), raising the module up from a surface a few cm could make a difference.

3) Shielding
The antenna must not be shielded by something conductive (like a faraday cage). An example would be a metal fridge or freezer, or a metal range hood. A metal wall box would be bad, use a low voltage plastic one. You can put the modules inside a metal enclosure, but the range is likely to be severely reduced.

4) Attenuation
Objects between the module and gateway will refract, reflect and attenuate the signal. Try to avoid objects in the signal path if possible. I know, people, walls, doors etc. are not something that can be planned for, but if you have the choice, minimize obstructions as far as you can. This could be as simple as avoiding the areas of walls/doors that have wood/metal behind them (like wall studs for example).

5) Orientation
An ideal monopole is isotropic (ie radiates in all directions equally), in reality this is rarely true. so the module/gateway will have greater range in some orientations than others. Due to the principal of reciprocity, if the transmit signal is better in one direction than another, then the receive gain will also be better in the same direction (ie the transmit and receive functions for an antenna are the same). This is why boosting the power/gain at one end of a radio system does not work, you have to either boost both tx power and rx gain, or boost tx power or rx gain at both ends.

Slightly adjusting the orientation of a module/gateway can make a connection better or worse, and is worth some experimentation with long range modules.

Polarization may also be important. Monopole antennas are polarized in the plane of the antenna, usually horizontal, or vertical. If the polarization is different between a module and the gateway, there will be a signal loss. Theoretically a 90 degree difference (ie module vertical and gateway horizontal) could result in a 20dB signal loss. In reality it's probably less than this, but it is a factor!

In summary, I have found that some module I though were out of range, could be brought back in range by adjusting the positioning/orientation of the gateway. this will be a compromise, but it is worth considering in the placing of modules/gateways.

The quoted 200m range is obviously under ideal conditions, and is the maximum possible. In the real world, a range of 30m would be considered good.

These are my thoughts on range and antenna considerations, it's a long time since I was designing antenna's, so please excuse any errors, also feel free to correct any bad assumptions or mistakes I have made.

FYI I believe the design of the antenna is based on this: http://www.ti.com/lit/an/swru120b/swru120b.pdf

I hope you find this useful.

Pages: 1 [2] 3 4