Upgrade Ver2 See's No Others

[BitManip]

Ok, I went from the Ver 1 to Portal Update 2.0.25. I did the ver migrate as your pdf advised and the serial port worked to find the unit and upgraded to a ver 17. That was the Coordinator module. I then did the End Device w/o Amplifier and it upgraded OK. The MAC Id's of each can be seen correctly as the label show and I can upload a sample demo. However when I replug my Coordinator and turn on the End Device on another board I can not get the End Device to show up in the Node window even when I have verified the Channel and Address are identical. What am I doing wrong? Please Help.

[kbanks]

For starters, grab the Portal 2.0.30 build, and install that.

This will give you access to the 2.0.22 build of SNAP.

Please upgrade all your units to SNAP 2.0.22.

Remember, now that you have migrated from 1.x code to 2.x code, all future SNAP software updates should be done using the "firmware upgrade" menu option, not the "migrator" menu option.

The SNAP 2.0.22 firmware includes a work-around for a problem we recently discovered with some of the newer radio chips. There is a small possiblity you are running into this problem, since your serial communications seems fine, but your radio communications is giving you trouble.

So let's eliminate this possibility by loading the latest code, and then go from there.

Kevin Banks

[BitManip]

Did the download of 2.0.30 & did the Portal reinstall. Went fine with the Firmware upgrades on each device Coord & End Dev. All went the same, Channels on both are same, Net ID's on both are same. One diff I see on looking into the Config Param is the Coordinator is named 'Coord' and the End Device is left blank in the name field. However most of the Param are the same except the Feature Bits and the Default UART. I use the USB with the Coord after firmware updating and the serial port with the End device to update but then disconnect when I try to link. I also notice that the Link Qual is at 0%. Thanks, Awaiting your reply.

[kbanks]

When you are directly connected to the nodes, which SNAPpy script are you uploading into them? You might want to start with McastCounter.py, if you are not already doing that.

Also, a note about link quality. SNAPv2 AKA SNAP Pro nodes do not automatically display link quality on their seven segment displays. Instead the seven-segment display is under direct SNAPpy script control.

It is possible to display the link quality on the display from a SNAPpy script, see example script LinkQualityRanger.py for an example of that. Just realize that this is not always being displayed, unlike what you may be used to from SNAPv1.

If you are loading the "McastCounter.py" script, the "00" you see on the display is the initial count, which will increment on all nodes when you push the select switch on any node also running McastCounter.py.

This script also gives you an easy way to verify that all the nodes are able to talk to each other. Pressing the select switch on any node should increment the displayed count on all other nodes that can "hear" the first node.

So, load "McastCounter.py", and see what happens when you press the node buttons. I will go back and re-read your previous posts and see if I get any other ideas.

Kevin Banks

[BitManip]

Ok, I got to testing some things with each device (Coord & End Dev), and I had reset each device several times by power down and then up again. It still was the same way, no communications of the remote node. Then I did a Portal "Factory Default NV Params..." out of the Options menu. After again resetting the devices, each saw one another. The Config menu show that the Net ID got reset to the default and stayed Chnl 4, so I again reset each Net ID to the same I had previously and they still talk to one another. Now the only thing different in the Config panel is the Feature Bits, but thats understandable the two are different in that they dont both have amplifiers. One says oxf and the other is 0x1f. I then changed the Coord to work with USB and left the other with Serial. Still worked, and both show no name in the Device Type. Go figure? :)

Now to answer your Q: on what I didn't see when I was inserting this Post. I uploaded the "evalBase" script to each cause it allowed me to write digits directly to the 2 digit display. Now on the previous vers firmware 17 I was not able to upload all scripts as some come up with an error saying some of the programs 'getXX() was not supported. I tried all of the scripts that were avail in ver 17 and found only 3 or 4 to download. The otheres all gave various errors. I now notice you included a lot more in this ver 22 and will now give it a try again. By the way it was the evalBase that was loaded into each unit that when I got it to suddenly work.

[kbanks]

It is possible that you are still running on the default of channel 4 and Network ID 0x1C2C.

When you change those config parameters, you are changing the contents of a block of non-volatile memory. This block of memory gets read and system startup, and programs the network ID, channel, MAC address, etc. at that time.

Changing these parameters does not directly affect the "live" settings.

So, you should probably visually verify the settings on your nodes match, and then reboot them to verify that they will in fact communicate using the saved settings.

Also a comment about evalBase.py. This script is meant to be imported from other scripts, not loaded by itself (look inside McastCounter.py for example). SNAPpy script evalBase.py by itself will not do much. If you look at that script's source code, you will see that it has no "startup code". You would have to manually call one or more of the functions defined in that script for any of that code to actually be executed.

I think it was the "factory reset" that got your communications back online.

Kevin Banks

[BitManip]

I now tried erasing the script in the End Device and reloading the "McastCounter.py" and I get an error: "An error occurred while creating the snappy image: 'unicode' object has no attribute 'getmod'.
Now 'getmod' is not listed in the "BuiltIn" module. I even found that some of the errors that poped up when I was trying the ver 17 that the function was listed in the BuiltIn module even though it said it ws not found. What can I try next? Maybe I will try some of the other Snappy Images to see what will or not load.

Thanks :D

You say I would have to try manually one or more of the functions in that script....Thats what I did. I found the function: "display2digits(value)" to work fine on either device. On changing the Net ID, each time I did change it I verified on the ....lets say Boot up after power down that the script showed the correct ID, Channel etc. Only When I did the NV reset that changed the ID back to 0x1C2C did it begin to work. I then changed it back to what I had it before : "0x002A" and it now communicates and the script shows when booting the correct ID and the Node window also.

[kbanks]

We are currently trying to track down the getmod() error - it only happens on certain PCs (and it does not happen on any of the developer PCs).

Kevin Banks

[BitManip]

Lets say that all the filename.py files gave the same error about 'getmod' that I mentioned priviously except: buzzer, evalBase, flexiBase, KBIsupport, PinWakeup, and Switchboard. I can view the filename.py with the FILE -> OPEN SCRIPT out of the pull down menu of Portal but I cant upload most of them. Am I doing something wrong?

[kbanks]

Yes, you can invoke functions manually. This comes in handy when writing new scripts (you can invoke individual functions manually to test them).

You can invoke them by clicking on their name in the Node Info pane. You can also invoke functions from the Portal command line window.

Assuming you have a node at address \x12\x34\x56, from the command line you could do something like:

rpc("\x12\x34\x56","display2digits",42)

[kbanks]

Lets say that all the filename.py files gave the same error about 'getmod' that I mentioned priviously except: buzzer, evalBase, flexiBase, KBIsupport, PinWakeup, and Switchboard. I can view the filename.py with the FILE -> OPEN SCRIPT out of the pull down menu of Portal but I cant upload most of them. Am I doing something wrong?

I don't think so. What version of windows are you running?

[BitManip]

I am up with 'Windows XP Pro ver 2002" 5.1 (Build 2600.xpsp_sp2_rtm....Service Pack 2) This is a stand alone system not on any network and has been loaded by myself as a duel boot system. I am using an 1.4 GHz, P4 with 500 MB RAM on an Intel D850GB Motherboard.

[BitManip]

I did some comparisons of the loading filename.py scripts vs the non-loading (ones that gave the getmod error). Of all the ones that loaded I noticed that none had a command to 'from filename import *' in it; and visa versa, all errored filename.py had it. So I experimented and took the image script : "flexibase.py" and commented out the first part of the (Switchboard "D"ata "S"ource parameters) section and replaced it with a line : {from switchboard import *} (brackets not included). I tried to load and got the getmod error. You may have known this already but thought it interisting and may help.

Thanks for listening:)

[mgenti]

We have just released version 2.0.31 that should include a fix for the problem you were seeing. You were correct that it only affected scripts that imported others scripts.

[BitManip]

OK, I got it hummin now. I can upload image scripts via direct connect and over the RF radios....FANTASTIC! I am not a Python programmer as of yet but I am getting the hang of it. I understand how Python scripts import other scripts so I ask, Q: Of all 19 image scripts that I see (two of them KBIsupport & pinwakeup being the same, and I dont know if that was planned or what), which image scripts are to be used as the full demos? I know I can load each by itself and instigate certain functions by double clicking on parts, but I see the following as what appears to me to be the full demos: McastCounter, DarkRoomTimer, LunarLandar, DarkDetector, EvalHearBeat and lowpower. Am I missing any others?

Thanks

[kbanks]

KBIsupport was recently renamed to pinwakeup. Key Board Interrupt (KBI) is what Freescale calls that hardware feature, but we decided it was too confusing. Since the Portal installer ADDs new scripts, but leaves existing ones alone (for all Portal knows, KBIsupport.py is a new script that YOU made), you have been left with an extra copy of the file under its old name. You should delete KBIsupport.py, and use pinwakeup.py from now on.

BTW, the manuals I mentioned earlier just got posted to this forum by Mark Guagenti.

The documented demos are McastCounter, DarkDetector + buzzer (these two are used together), and LinkQualityRanger.

(I assume you understand I am omitting the .py extensions here)

Additional demos are CommandLine, DarkroomTimer, EvalHeartBeat, gpsNmea, ledToggle, lunarLander, protoFlasher, protoSleepCaster, and switchboard.

evalBase and pinwakeup are meant to be included by other scripts. Note that evalBase was recently changed to import pinwakeup, so if you import evalBase you now automatically get pinwakeup too.