UPDATE - DNS over NB-IOT is now working!
Please update to the latest 1.18.2 (stable):
or to the latest 1.20.0.rc7 (development):
Use the following to set your DNS Server to Google's DNS Servers ...
Then bring up your LTE Connection, and do:
>>> print(usocket.getaddrinfo("www.google.com", 80)[-1])
@ferfersan6 Good intentions pave the way to hell and I had every intention to reply to this. I know this is WAY too late to reply this but may useful for any experiencing the same issues.
If I remember correctly, I just held the pin high for as long as possible and went through the drudgery of reinstalling the proper firmware. Nothing sophisticated going on here! :)
@NickBoots boot.py and main.py share the same namespace. If you import pytrack in boot.py, you do not have to do that in main.py again. Actually that would be ignored.
So either way is fine, but in your case does not matter much anyhow. boot.py and main.py are executed one after the other, with just a few ms time in between. So it is more a matter of software design than a difference in energy consumption.
@NickBoots Everything IoT would be too broad... But I agree, expertise from Pycom forum, various sub-reddits, micropython.org forum. Having a single place to go to would be nirvana. Maybe that's the next evolution of social networks?
@Berli 13.56 MHz (HF) RFID/NFC is really not designed for long distance scanning. That's something that is usually done using UHF (433 MHz or 868/915 MHz) instead, using active tags (which have their own power source).
Don't forget that in your situation:
the reader needs to provide power to the tag
the tag needs to wake up and engage dialog with the reader
there can be several back-and-forth exchanges between the tag and the reader
all of this needs to happen while the tag is in range of the reader
The range over which HF RFID works is usually counted in centimetres, not meters.
I don't remember the exact details, but I believe it's the reader that initiates the conversation by "scanning" for tags, so this means you would also need to take into account the scan interval.
In addition, if the tag is moving too fast, you may have Doppler effects to factor in (which will shift the frequency up or down).
What kind of distance are you trying to cover, what kind of speed are your considering, what kind of tag are your using? Does the tag have its own power source?
Indeed, the reference board schema's are presenting a 0R to prevent the VDD33 from being fed by the VDD5. But there is nothing documented about removing it to work on the G01. And the datasheet and pinout schematic are ambiguous about being in input or output.
So I'm not gonna order a batch of prototypes on documentation that is clearly out of date. Nor do I think it is very efficient for us to be figuring this out. Maybe @Fred can give us a hint or knows somebody who should know?
I have a really serious issue with Atom and PyMakr. I've been posting the bug reports to the PyMakr and Atom Github forum. I've updated my Atom to 1.40.1 on Mac OSX, running version 10.13.6.
I'm using PyMakr 1.4.16. But I'm getting...
Uncaught Error: Could not locate the bindings file. Tried: → /Users/johndraper/.atom/packages/pymakr/node_modules/@serialport/bindings/build/bindings.node → /Users/johndraper/.atom/packages/pymakr/node_modules/@serialport/bindings/build/Debug/bindings.node → /Users/johndraper/.atom/packages/pymakr/node_modules/@serialport/bindings/build/Release/bindings.node → /Users/johndraper/.atom/packages/pymakr/node_modules/@serialport/bindings/out/Debug/bindings.node → /Users/johndraper/.atom/packages/pymakr/node_modules/@serialport/bindings/Debug/bindings.node → /Users/johndraper/.atom/packages/pymakr/node_modules/@serialport/bindings/out/Release/bindings.node → /Users/johndraper/.atom/packages/pymakr/node_modules/@serialport/bindings/Release/bindings.node → /Users/johndraper/.atom/packages/pymakr/node_modules/@serialport/bindings/build/default/bindings.node → /Users/johndraper/.atom/packages/pymakr/node_modules/@serialport/bindings/compiled/10.2.0/darwin/x64/bindings.node
There is an active thread on GitHub, but the reason why I'm posting this here, is because of this month long issue which IMHO has NOT been solved as far as I'm concerned, now my job is in jeopardy. I'm more then 2 months behind in my work, I'm unable to contact the developers and I discovered that the "Install" script is full of bugs. Let me explain.
First off, following the error message I get, it gives a path that includes a "build" directory, as well as a "Debug" directory. On my machine, I don't have these following directories in my path to node_modules....
As you can clearly see, this path is different then what PyMakr displayed, and there is NO "Debug" or "build" directory in that path. It seems the people in the github forum seems to have ignored my statement and subsequent postings.
By the way, before installing Atom, I completely removed my ~/.atom directory so the newly installed Atom could re-build them.
After that, one forum member posted this:
npm install @serialport/bindings
ln -s ~/.atom/packages/pymakr/node_modules/@serialport/bindings ~/.atom/packages/pymakr/node_modules/serialport/bindings
Others claimed it worked, but for me, it didn't. Probably because I'm on a Mac OS. I really just did not know.
I want others to know about this serious issue, so they don't "Walk into a trap" like I did.
Bottom line.... current PyMakr does NOT work on Atom. The install script has bugs I pointed out in the issue #134 on the Github bug list.
Absolutely NO workaround ever presented to me has worked.
Fact: I'm more then 2 months late in delivering a project, and now my gig may be ripped from under me, just because I believed that the Pymakr developers were doing their jobs, they are not. And now MY job is at risk.
I respectfully request that the PyMakr developer contact me. I live in USA in Las Vegas. I can be reached at +1 818-640-5290. I'm on Signal, Telegram, and WhatsApp, as well as Riot as firstname.lastname@example.org
I am a disabled vet, so my brain is not often up to par with most people.
I'm posting it here for two reasons...
Reason #1 - to tell others planning to use this product that it's broken, and there are no workarounds, and for them to try using other options.
Reason #2 - to reach out to more people at PyCom to express my dissatisfaction and hardship I'm having in using these tools, as well as telling others intending to use Atom and PyMakr that they might want to wait until the product is a bit more mature before attempting to use it.