GHI Electronics NETMF 2016 SDK Pre-Release 1

Press Announcements
41

@ jjs -

Thanks
Modify Block_size 64*1024 then everything should be fine.
We will check it later.

42

@ John - I am working on a test of cellularmodule_43. It works better now, but still finding glitches. The IMEI function does not detect the IMEI number. RequestImei() never activates the event ImeiRequested().

43

Hi Niels,

The CellularRadio 4.3 module is flaky for some things and I have managed to get it working much better. PPP connection is now rock solid on my modem.

I was about to test the IMEI code this coming week and I am also adding some functions to get the MNC and MCC from it. These are handy for looking up the GPRS settings.

I can send you the code next week once tested and you can see if this is more stable for you? It’s not Gadgeteer though as I ported it to pure NETMF. Easy to copy and paste what I made changes to. I’ll be sending it to John soon too.

44

@ Dave McLaughlin - Hi, I know, and I am waiting with excitement on your progress, keep me posted :smiley:

For this specific test though, on the Cerberus (without PPP) I am working on a SMS based command-line tool to control and get status from a remote system. I decided to see if the vanilla cellular driver from this pre-release could take its role…so far only the IMEI function does not work.

@ John - BTW these additions always go into the driver when I start working with it, why not put them into next release?

       
       private void OnLineReceived(CellularRadio sender, string line)
        {
            DebugPrint("Line received:" + line);
            if (Program.CheckAndInvoke(this.LineReceived, this.onLineReceived, sender, line))
                this.LineReceived(sender, line);
        }

        private void OnLineSent(CellularRadio sender, string line)
        {
            DebugPrint("Line sent:" + line);
            if (Program.CheckAndInvoke(this.LineSent, this.onLineSent, sender, line))
                this.LineSent(sender, line);
        }
45

The AT+GSN on my SIM5320 gives error and the correct command it seems is AT+CGSN so I can send this with SendATCommand

The reason for the failure is that the command does not send back the text GSN in the reply, only the IMEI so the code does not know about it. The code is looking for this but it never appears.

What you need to do is add handlers for the OnLineSent and OnLineRecieived and when you detect the IMEI request in sent, you set a flag and then handle the received. This works for me as below.


static void gsmModem_LineSent(CellularRadio sender, string line)
{
    if (line.IndexOf("GSN") >= 0)
    {
        WaitingForIMEI = true;
    }
}

static void gsmModem_LineReceived(CellularRadio sender, string line)
{
    if(WaitingForIMEI)
    {
        WaitingForIMEI = false;

        GSMstate.IMEI = line;
    }
}
46

@ Dave McLaughlin - That matches my first investigation, and I think your proposed solution is meaningful to solve the problem. Still not sure why there is no “wrapping” around the IMEI though…

47

Because the code is not designed that way. There is no send, wait and send back reply. Actually, the OnSent and OnReceive make it way more powerful now that I have discovered that option. :slight_smile:

48

@ njbuch - @ Dave McLaughlin is correct. The AT+GSN and AT+CGSN commands send the IMEI back raw instead of in the usual format “+GSN: xxx” the driver expects. Unfortunately, fixing it will not make it into this SDK.

49

@ John - I agree, this is not a serious issue. The socket/pin reservation is much more critical :wink:

50

VS2015 works the same as VS2013 after changing back the compiler using this fix: https://www.ghielectronics.com/community/codeshare/entry/1053
Why did you stop to support it? Are there any other issues besides the compiler?
Two versions of VS are too heavy for my 120gb ssd in the laptop. :frowning:

51

@ toxsedyshev - Maybe someone will correct me, but officially VS2015 was never supported by GHI.

52

@ toxsedyshev - That Codeshare does not fix the problem 100%. A lot of issues remain around VB support.

53

@ John - So, if I don’t use VB, could I use latest GHI SDK with VS2015 or it is not supported at all now?

54

@ andre.m - Maybe “not supported” and “wont work at all” is not the same?

55

NETMF with GHI Libraries V4.3.7 and without Gadgeteer and C# only works perfect for me in VS2015 with the Codeshare Fix script for the Compiler.
But I don’t have the SDK installed.
I only install the GHI Drivers (manually) and run FEZConfig without Installation.
Then I add the GHI References manually (Browse) to my Projects.

So far me and my Colleges did not have a s single issue since we switched to VS2015.

56

I work with the nuances with support all the time.

  • If you can test all scenarios and know they work as you expect, then that combination becomes supported.
  • If you test and some scenarios fail, you can either document those tests that fail and a workaround if that is all that doesn’t work (supported with caveats) or you chose not to support it until the issues are resolved. [ if the issues are going to be externally addressed, it makes sense not to offer any level of support ]
  • If you don’t do a complete test then you don’t know for sure what does and doesn’t work.

that doesn’t mean that you can’t use empirical evidence like “my colleagues all use it” to influence a decision; but you should also use the evidence that when GHI don’t publish something that states “we have this little quirk you need to know about” to influence you. At some point an end user has to think is this worth my stepping into the unknown and maybe hitting things that don’t have a clear workaround, or should I use the supported scenario and wait. [quote]“not supported” and “wont work at all”[/quote] are very clearly two different things, and if you’re willing to work around any documented issues then it’s your call to use an unsupported configuration, but there’s a worse scenario, you may not know you’re having an issue, and may not be able to work around it, and finally nobody else (besides the community - and that may only be patting you on the back and saying “there there, chin up”) will be able to assist you resolve it as it’s not a supported configuration.

Jump if you must, but know you’re in that not-supported danger zone.

57

@ Brett - just so you know, we did a complete analysis and forwarded to Microsoft. If there is a simple work around we would have done it already.

58

Yep, I’m sure you did and I’m sure you would have told us all the issues and workarounds if it made sense to do so; it was certainly a longer list than the workaround that was posted in codeshare, even without knowing all the things on the list. That doesn’t change the point - the decision each individual needs to make is if the unknown is worth a jump for them to take with what they know (and what their friends/community says) but do it knowing that there is no option for support if they do…As a home hacker I might decide the risk is OK for me, but if I didn’t feel confident I could decide if any issues I faced were in my code alone, I may choose to stay fully supported… but only I can make that judgement call of what I am and am not comfortable with

59

I really hope we can cleanly solve this soon.

60

How should TinyBooter be updated on FEZ Raptor? I short pins 8 and 10 on socket 3, restart, make sure that I see “Bossa Program Port”, start updating procedure in FEZ Config and get “Could not connect to the device!” error. Tried the same procedure on another PC and got the same result. Updating the old way with SAM-BA does not seem to be possible anymore as there is no “Update Loader.bat” and some other files. So, how should I update it?