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 4 ... 15
mc-Demo205 / Re: Tilting Trigger on the Accelerometer
« on: February 27, 2017, 05:40:47 pm »
You're decoding the float wrong. The floats are 4 bytes little endian.

What you get is:
1 byte (0x08) - which decodes as 8
4 bytes of integer (0x02000000) - which decodes as 2
4 bytes of float (0x6f12833c) - which decodes as 0.016

1 byte (0x08) - which decodes as 8
4 bytes of integer (0x01000000) - which decodes as 1
4 bytes of float (0x250681bf) - which decodes as -1.008

1 byte (0x08) - which decodes as 8
4 bytes of integer (0x00000000) - which decodes as 0
4 bytes of float (0xa69b443d) - which decodes as 0.048

Exactly as expected.

You were putting three bytes of 0x00 before the float to decode. Remember byte = 1 bytes, integer = 4 bytes, float = 4 bytes - total 9 bytes.

mc-Demo205 / Re: Tilting Trigger on the Accelerometer
« on: February 27, 2017, 03:26:54 pm »
Yes, there are some bugs is mcStudio. To get the shared function to work you have to:

Code: [Select]
Dim value as Float = MotionLocation.getOrientation(0)

Then use value in your SigFox publish. I know it's a pain and it does work as is, but Private is not correct (because your class is not instantiated)- this isn't the problem though.

The range isn't 0 to 1 as such, it's +/- range so whatever you set in setup (2G I think, so it would be +/-2.0), it's just that earths gravity is 1.0, so if the module is not moving, you should get +/-1.0 on one axis, and 0 on the others, if the module is level.

Why you get 3.961e+28 for the X axis, I don't know, but the values from the accelerometer are correct. have you tried just substituting fake numbers (like 0.01 and 1.01) for the X,Y,Z float values, and see what shows up in losant? I suspect the math is wrong somewhere in the SigFox - losant chain.

How are you extracting the float in Losant? it's an IEE float representation so it's not a simple extract unless losant has a way of extracting IEE floats.

mc-Demo205 / Re: Tilting Trigger on the Accelerometer
« on: February 27, 2017, 09:33:38 am »
Ok, I have it working, as is!.

There are a couple of problems, mostly minor. First, your GetOrientation() function is declared as Private, which is not valid (but does work due to a bug in mcStudio) it should be shared, and then referenced as MotionLocation.GetOrientation(). You can leave it as it is, but just note that this is not strictly a valid definition.

Second, you have mixed two of my examples together. The "EndMotion" example uses accel.ConfigureTransientInterrupt(0.15, 20.0, 1, 1, True), which you have changed to accel.ConfigureMotionInterrupt(1.15, 20.0, 1, 1, True). This is important as they are two similar but different things.

ConfigureTransientInterrupt uses the High Pass filter, hence the example has all the enabling and disabling of hpbypass to get absolute values.
ConfigureMotionInterrupt does not use the High Pass filter, so no manipulation of hpbypass is needed to get absolute values, but the threshold value has to be greater than 1.0 to prevent the interrupt triggering constantly because of earths acceleration due to gravity.

Having said that, it doesn't matter, you just don't need it.

So substituting MQTT.Publish for your SigFox publishing (we don't have SigFox in Canada), I get this:

Code: [Select]
MCThings/00020004/Sigfox 0 -0.064000
MCThings/00020004/Sigfox 1 0.064000
MCThings/00020004/Sigfox 2 -1.008000
MCThings/00020004/Sigfox GPS 43.601692,-79.708992

Which looks correct (Z is -1 as it depends which way up the module is). This is without changing your code.

I would remove the hpbypass stuff as you don't need it (you don't need accel.ReadConfiguration(0) either unless you want to see the accelerator configuration):

Code: [Select]
    Private Function getOrientation(type As Integer) As ListOfByte
        Dim accelValues As ListOfFloat = accel.GetAccel()
        Dim PitchRoll As ListOfFloat = accel.GetPitchRollDegrees()

        Dim msgData As ListOfByte = New ListOfByte()
        msgData.Add(0x08) '08 is an indication to Losant that this payload contains location data
        'msgData.AddFloat(accelValues(0)) //x
        msgData.AddFloat(accelValues(type)) //y
        'msgData.AddFloat(accelValues(2)) //z
        Dim top_msg As String = "Sigfox " + type.ToString()
        Dim msg_payload As String = accelValues(type).ToString()
        MQTT.Publish(top_msg, msg_payload)
        Return msgData         
    End Function

Boot() event
Code: [Select]
'Nicks's setup:                 
                accel.Setup(LIS2DH12.LOW_POWER_MODE, LIS2DH12.DATA_RATE_50HZ, LIS2DH12.SCALE_2G)               
                accel.ConfigureMotionInterrupt(1.15, 20.0, 1, 1, True) 'INT1 pin 1, Latched. Pin 1 activates AccelerometerInt1()
                'accel.ConfigureTransientInterrupt(0.15, 20.0) 'same as above
                'accel.ConfigureTransientInterrupt(0.15, 20.0, 1, 1, True, LIS2DH12.INT_SRC_YH) ' as above, but only Y High axis interrupt enabled
                'accel.SetFilterBypass(False) 'disable HP filter bypass (values read will be with HP applied - usually this is enabled, or you just read 0's with interrupts enabled, but gets re-enabled in Publish() )
                'To publish a paramterer value to Sigfox insert the corresponding number.
                '0= general control registers
                '1= Interrupt 1 settings
                '2= Interrupt 2 settings
                '3= Click Interrupt settings
                '4= Misc others
                'Dim accelconfig As Json = accel.ReadConfiguration(0) //general control registers
                MQTT.Publish("Status", "Online")

If you are getting 0's in losant, its due to something else. I do notice that you are publishing to SigFox every 20 seconds. This does not seem allowable by SigFox, as they restrict you to 140 messages per day, or one per 10 minutes. Maybe they don't restrict frequency, just the total number per day - as I say we don't have SigFox so I don't know. Once per 20 seconds does seem a bit fast for SigFox though.

Anyway, your code does work as is. Your problem is elsewhere.

Hope this helps.

mc-Demo205 / Re: Tilting Trigger on the Accelerometer
« on: February 26, 2017, 04:51:22 pm »
I think that was more in the way of an example, normally you leave it on true, and you don't need to do any of the other stuff - dummy read, sleep etc, you just read GetAccel().

To explain the HP filter, when it is enabled, it removes the DC component (caused by gravity ie 1). This is what is then used by the interrupt routines (except orientation). So if you want an interrupt to trigger on acceleration of 0.5, with the hp filter on, gravity is ignored, and it triggers when the change of acceleration exceeds 0.5 (otherwise it would trigger all the time as acceleration due to gravity is 1.0).

If you read GetAccel(), you would read 0 for X,Y and Z, unless you were shaking the module or something.

So to get the real reading, you turn hpbypass on, now the readings from GetAccel() are the absolute values (including gravity). The interrupts are not affected, they still use the filtered values.

Anyway, I'll take a look tomorrow, and see what I can do.

mc-Demo205 / Re: Tilting Trigger on the Accelerometer
« on: February 26, 2017, 02:45:06 pm »
I'll try this on my 205 tomorrow, first thing I notice is that you keep tuning the HP bypass on and off, why not just leave it on? if you accidentally read with bypass off, you'll just get 0's.

Announcements / Re: Announcing mcStudio Version 0.9!
« on: February 25, 2017, 07:52:27 pm »
Looks great!

I may have some rewriting to do, but it looks like I can scrap some old work arounds in the process.
Thanks for clearing up the divide confusion, and thanks for arctan2 (now I can get rid of the one I wrote)!

Yeah! for threading and Thread locks. And finally a long data type! Awesome!

Quick question about pins, I see you have methods value and voltage. If I read an analog pin value (not voltage), do I get the underlying digital value ( ie 0 to 1023 or whatever the bit resolution is)? I'm usually interested in the value, not the voltage, so I have to constantly divide by Vref (3600). It would be great to be able to read the value and not the voltage.

Also is it possible to set the analog resolution? I believe it's 14 bits at the moment, but it would be great to set it to say 10. Just a suggestion.

Looking forward to the new release.

mc-Demo205 / Re: Tilting Trigger on the Accelerometer
« on: February 24, 2017, 08:21:52 am »
Glad you found them useful!

The values for X,Y,and Z are in gravities (g) so Z should usually read 1.0 (depending on the orientation of the module). X and Y would read 0 (no acceleration). As you rotate the module in 3 axes, the values would change from 0 to 1.0.

Can you post your code? I can look at what you are reading.

mc-Studio / Re: How to use enums?
« on: February 17, 2017, 11:32:45 am »
I've used enums in many cases, lots of the libraries use them, but in all cases they have to be declared outside of a class.

Take a look at the MQTT, accelerator or Timer libraries to see how we are using them.

mc-Module / Re: OTA Update
« on: February 10, 2017, 10:19:29 am »
Well I still have endless trouble updating scripts OTA.

Usually connect goes without much trouble (especially if I have midpowermode set).

Then to send the script, I click on "Load and Save Program" - Icon highlights, then there is a period of nothing - 10 to 30 seconds (depends how long the program is). Next subtle change in the McStudio window (icon flickers, or windows spinner starts - something like this) - I know this means that building has finished, and transfer to the module has begun. Now random period of nothing, McStudio is unresponsive (can't do/click anything) - this can be 15 to 30 seconds or so. Next you get one of the following

  • Success message
  • Failed to Load message
  • Nothing - continuation of what I call "hung" mode

In the last case, I have tried waiting minutes, but no change. At some point I give up, and have to power cycle the module, at which point I get a long pop up error message "object not sent to an instance of .... blah blah blah". Click on OK. Now windows comes up and says McStudio has stopped responding - click on "close program". McStudio closes. Re-open it (usually twice, first time fails), and try again.

This happens 50 to 80% of the time (i think it depends on how far the gateway is from the module but this may be wishful thinking. I usually have the module 50cm from the gateway or it doesn't work at all).

My suggestion - what about a progress bar? ie compiling, building, sending so you can see what is happening, and if it is hung. Maybe retry instead of crash?

It's just frustrating having to wait "random length of time" not knowing what is happening, looking for subtle windows changes to guess progress, eventually giving up and so on.

I know my computer is slow (I do have a faster one, but it's not set up for development ... yet), and my main super fast computer is Linux, but it's not that slow! It's running Windows 8.1 if that is any help.

Just what I'm seeing, YMMV.

mc-Module / Question about Division
« on: February 10, 2017, 09:56:18 am »
I know that it was mentioned a while ago that division always returns a Float.

So I have been doing things like this:

Code: [Select]
Dim Value As Integer
..... stuff
Value = ((Value + List(currentsample)) / 2).ToInteger()

everywhere. Now I have to say this seems to be odd behavior, as most languages would simply do integer arithmetic in this case. If I were to do this:

Code: [Select]
Value = ((Value + List(currentsample)) / 2.0).ToInteger()

I would expect to have to cast to an integer, as 2.0 is explicitly a Float, and so Value etc. would usually be promoted to a Float.

This means that common constructs like:

Code: [Select]
Value /= 2

Don't work as Value is an Integer and the division returns a float (but Value *= 2, +=, -= etc do work - this seems inconsistent).

Looking at the documentation, it gives two division operators (never noticed that before!).

This is what the documentation says:

Shared Operator /(x As Integer, y As Integer) As Integer
Shared Operator \(x As Integer, y As Integer) As float

So according to the documentation, / should return an Integer, and \ should return a float. In fact, having tested this, it is the opposite way round.

So this does work:

Code: [Select]
Dim Value As Integer
..... stuff
Value = (Value + List(currentsample)) \ 2

And Value \= 2 works too!

I would really like to go through my code and remove all the unneeded type casting, but I'm not sure which is the right form. The documentation does not agree with the compiler.

So which is right? should I refactor my code, or will the compiler be fixed and I can just take out all the type casts as is (in the future)?


mc-Module / Re: OTA Update
« on: February 09, 2017, 02:50:46 pm »
Yes I have completed the updates,

I have to say the computer that I am working on is very slow though. Could it be a timing issue?

mc-Module / Arrays (Lists)
« on: February 09, 2017, 11:48:43 am »
I have 7 arrays (listofbytes), and I was looking to find a way of making them into a 2D array. ie a listoflistofbytes.

I was looking at listofobject as a way of adding a listofbyte to a listofobject, so that I have a listofobject with 7 entries, each it's own listofbyte.

Would this work? I don't want to go too far down this route if it's a dead end. It's confusing enough with all the listof things to deal with, without getting into lists of lists...

Another thought was to use a class as a container for lists.

What do you think is the best way to make a 2D array?

mc-Module / Re: OTA Update
« on: February 09, 2017, 11:43:46 am »
Do you actually mean OTA update? or just sending a script to the module (wireless)?

I ask, because I have had no real problems updating the firmware on 120 modules, but getting scripts to load via wireless is very difficult.

For this reason I mostly use my dev board, which has no problem loading (if you get the on switch - connect timing right).

But in some instances (wired in modules), I have no choice but to update them with new scripts using the gateway, and this fails about 80% of the time. Before the latest updates (yesterday), I was successful most of the time if the gateway was next to the module (ie less than 50cm say). Further away than this would fail every time.

After the upgrades released yesterday, updates fail most of the time, even with the gateway 5cm from the module. This is a pain, because you mostly get no message, things just hang. You have to power cycle the module, which crashes mcStudio, then restart mcStudio (usually twice as it doesn't start the first time), and try (and fail) again. Very time consuming.

The new firmware seems more prone to these failures than previously. As I say I was mostly successful when the module was within 50cm of the gateway, now 80% failures. It's early days with the latest upgrade, but I have noticed much lower reliability on script transfers already.

Did something get messed up?

mc-Module / Re: AnalogInput units
« on: February 07, 2017, 07:01:33 am »
OK, so your reference is 3600 though, not BatVolt as I suspected.

I'll stick with what I have, no-one needs 14 bits from an on-board ADC, I need 10, same as most applications out there.

BTW, don't you have to oversample to get 14 bits? the built in is only 12 bits. That would slow down the response quite a bit, and seems somewhat pointless. Why not stick with 12 bits? it's more than most applications could possibly need, no-one expects nanoVolt precision from these devices.

mc-Module / AnalogInput units
« on: February 06, 2017, 09:18:21 am »
I'm reading an analogInput pin, and I would like to convert the reading from mV to voltage independent units (ie 0-1023), as the battery voltage may vary.

I'm currently assuming that reading the Battery Voltage will give me the maximum value (1023 units) and using the following to convert:

Code: [Select]
((1023 * reading) / batvolt).ToInteger()

However it occurs to me that this cannot in fact be correct (or the battery voltage would always read maximum), so there must be an internal voltage reference.

The documentation does say this "When a pin is in “AnalogInput” mode, the system reads the value based on the internal band-gap reference value."

Reading the data sheet, the internal reference is 0.6V, so assuming a gain of 1/6 this would give a range of 0-3.6V (which seems to be the case).

This would then make my conversion:
Code: [Select]
((1023 * reading) / 3600).ToInteger()

Is this correct? am I making the correct assumptions here?


Pages: 1 [2] 3 4 ... 15