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.

Messages - Nick_W

Pages: [1] 2 3 ... 15
mcCloud / Cloud Server seems to be inaccessible
« on: October 18, 2019, 12:50:59 pm »
I was updating my configuration, and replaced the batteries on my sensors, but not getting any events through.

So I tied to log in to my McCloud account, and the portal `` ip addreess is not resolved.

Are you guys still running? the link from your own web page to the portal also does not work.

Any News?

MQTT / Re: mcStudio cannot find Gateway
« on: June 29, 2018, 01:10:38 pm »

Sounds like you have the wrong version of McStudio. there are two versions, the legacy version (0.9) and the McCloud version. What you need is the legacy version. get it from here

What does help->about McStudio say?


I have lots of examples and libraries for the accelerometer, check them out here

Hope this helps.

mc-Innovations / Re: mcModules goes cold
« on: February 11, 2018, 01:29:21 pm »
Did you make a case for it?

I'm looking to 3d print some cases for different batteries also.

mc-Things General Discussion / Re: DHT 22 support
« on: May 21, 2017, 12:20:33 am »

Yes, the Bosch sensors are nice sensors, they do temp/humidity and air pressure, I wrote a library for them. They are a bit more expensive though (about $20 each). They are low power also.

You can daisy chain I2C modules, if you can select different addresses for each (some let you select the I2C address via jumpers).

You can also define more than one I2C bus, each uses 2 pins, and you can define any pins you want as an I2C interface.

As you say, the micro controller world is different. Ultra Low Power mcu is another world again...

The modules themselves are great, the ecosystem is good (need a better gateway!), but the lack of a cookbook, is, as you say a major problem.

If the modules had a humidity sensor, you could just use 4 modules. Lack of a humidity sensor is the major failing point right now, as knowing temperature without humidity is mostly useless. At least In my applications.

Check out my github site, I have all my code/libraries there, plenty of sensor examples. No data logging yet, but it's a good idea. The modules have 20k ram, so you could store quite a few readings.

Google Nick Waterton github.

You extract the bytes as two IEEE 32 bit floats. There are quite a number of IEEE float32 extractors out there in google land. it's not mc code, 'cause you are extracting it in your environment at the other end of the sigfox link (and I don't know what that is).

I did help someone else with the same problem here in the forums somewhere, if you search carefully you can probably find it, should explain everything.

mc-Demo205 / Re: Get GPS data into 12 bytes
« on: May 20, 2017, 01:41:59 pm »
Yes, I did get his to work, I have it somewhere in my module 205 code somewhere....

My main problem was that the extract functions didn't work as advertised, so was packing stuff, unpacking to check and getting bogus results. Extract is now fixed (but pack actually did work OK).

I think I went over this with someone else here on the forums, they were having trouble extracting the float from a sigfox packet. It's actually quite simple, it was the extract giving bogus values that had me confused...

mc-Studio / Re: Timestamps
« on: May 20, 2017, 01:36:32 pm »
Checkout my Time library, everything i know about timestamps is in it.

BTW the module time is really the gateway time (obtained from NTP server), and sent to the module when it connects. Timezone doesn't really seem to work though...

mc-Things General Discussion / Re: TimeStamps
« on: May 20, 2017, 01:32:29 pm »
My Time library has this function in it:

Code: [Select]
Shared Function GetTimestamp(format As TIME_FORMAT, TimestampOffset As Integer) As String
used for unix type time stamps. Might do what you want...

mc-Things General Discussion / Re: DHT 22 support
« on: May 20, 2017, 01:29:13 pm »

It's very difficult to do this with the mcmodule, because of the timing of the pulses required for the DHT 22.

You'll notice that for all these sort of devices (one wire, like the dallas protocol DS18B20) in the Arduino libraries, the signals are "bit banged" - ie the lines are set high, then low with a specified interval (timing), you then listen on the line for the response from the sensor, and decode this as bits.

With the mc modules, they use an RTOS (Real Time Operating System) - which is how it seems to do many things at the same time. One of the limitations of an RTOS is that you are not able to send signals (ie bit bang) with precise timing. This is because the underlying RTOS can interrupt at any time whatever you are doing to service a routine with a higher priority (say service the radio for instance).

So, although you think you are waiting 100uS between pulses, the actual duration of the pulses can vary, due to other interrupts (which you can't turn off, unlike an Arduino).

Having said that, the timing requirements for these (and dallas) devices isn't that fast or precise, so you might be able to get them to work (even with the timing variability). I haven't tried yet, as they draw quite a bit of power when measuring (and a bit in standby) and there are other options out there (check out the HDC1000 or the Si7021-A20 for instance - Adafruit has break out boards for some of these, and they are quite cheap).

Another option would be for the mc module guys to build in the protocol(s) to the firmware (as they can control the timing/interrupts), but this is probably not a priority for them, especially given the power draw of these devices, which is not really compatible with a low power/battery powered device.

The I2C device's I suggested are only a couple of $ more expensive, but draw less than 10th (or less) of the power. That's 10 to 100 times the battery life!

I2C is supported out of the box by the mc modules, and lends itself handily to your stated objectives, at  fraction of the power 4 DHT22's would draw.

mc-Innovations / Re: Front Door Sensor via MQTT
« on: May 03, 2017, 11:39:47 pm »
Here is the module with the new nice white case (just as I requested)!

Latest code is on my github, with 110 and 120 module code. I'm still using my old 110 module, one day I'll upgrade it to a 120 module, but the 110 works fine.

mc-Module / Re: Problem with mcModule case working with magnets
« on: May 03, 2017, 11:17:58 pm »
I use a small separate magnet, intended for magnetic door sensors. It's the same size as the one that comes with the case, and is a small, white pill shaped, self adhesive item. About $3 each.  See here

This is what it looks like

Works great, gap can be 15mm and it still works. I have photos in my post on this forum about my door sensor (see here I now have my door sensor in an MC case, but use the same magnet.

mc-Module / Re: AnalogInput units
« on: March 22, 2017, 07:50:33 am »

OK I'm confused by what you mean by "reading". If you just take the value from the analog pin (no math whatsoever), you get the voltage in mV. ie 2.8V = 2800, 3.3V = 3300 etc. up to 3600 (3.6V) which is the maximum you can read. You can read this as a short or an integer.

I am doing this in several situations, and it works exactly as predicted. I haven't tried reading higher than the supply voltage though.

The problem is that having the value in mV is not very useful, as you have to translate it into some sort of meaningful number, and most libraries/code expects units, not mV.

The two formulae's I gave you convert the mV to units. One does 0-16384 (14 bit) the other 0-1024 (10 bit). it's simple, divide the analog pin value (mV) by the reference value (3600) and multiply by whatever you want as full range, to get the arduino-style number. Just keep your units and data types straight. ie 3600 (not 3.3), integer division (not float), in integer maths you multiply before you divide, to avoid rounding errors, and so on.

Just FYI, on your particle electron, analogRead() reads units, not volts. On the mc120, analogRead() returns volts, not units. It's the other way round. I think this is the root of most of your confusion.

If you can post your whole code, maybe I can spot what is going wrong...

mc-Module / Re: AnalogInput units
« on: March 21, 2017, 04:28:02 pm »

I think you are mixing float and integer types, plus the voltage reference is 3600 not 3.3.

What I think you are looking for is:

Code: [Select]
value = (sensorReading\3600)*16384

or for 0-1024
Code: [Select]
value = (1023 * reading) \ 3600

where "value" is an integer type. Due to some odd math in McThings, division (/) always returns a float, so unless "value" was a float, you would get strange results. To do integer division, you use \ as shown above.

This will give you a reading from 0 to 16384 (0 to 3.6V), or 0-1024 if you use the second version. 3.6V is the maximum you can read. Note: this is not 3.3V or battery voltage, but is based on the internal 0.6V reference - so you can't change it, or use another number!

You also need to keep your units and data types consistent, sensorReading is in mV, and is a Short, 3.3 is in Volts and is a float. This combination is probably causing all the headaches.

Good luck with the project!

I haven't had any issues, but I haven't touched it in a while. I had a few people contact me with problems, but mostly from not understanding how the accelerometer works, not the library as such.

I expect that with the impending release of V 0.9, lots of things will change though.

I'm sure there is a lot of room for improvement, but it should be good for testing as-is.

Pages: [1] 2 3 ... 15