Michael
Forum Replies Created
-
AuthorPosts
-
MichaelParticipant
I was able to verify, with a sniffer of sorts (TTL-to-USB), that the GPS module is beaconing at a 1Hz rate its various $G messages. The messages appear on the Weather Shield pin marked “RX” which, according to the schematic, makes it to the “D0” pin of the mDot – which should have been OK. I was not able to get the code to “get” anything however.
So after some scrutiny I found there are several jumpers on the UDK2 board, located in a cluster that’s identified as JP98. The default location of one of the jumpers disrupts GPS module’s TX output. (It appears to tie this output to another output from the 232 chip)
MichaelParticipant>>The TX pin should be first.
Sigh – after all my unraveling of the schematics etc I still got this wrong?
But does that affect the operation of the debug port?
MichaelParticipant1) I think the default for the GPS is 4800 – besides that should only screw up the GPS, not the USB debug port.
2) I tweaked my post probably while you were responding. Yes, it’s still busted with the standard.
MichaelParticipantYes, I was already using those pins as you recommend in your post
For my debug output I’ve had all along
Serial pc(PA_9,PA_10);
and later in the code, a call to
pc.baud(115200);
That worked fine for a few weeks…Then today I tried to add GPS functionality:
SerialGPS gps(PA_3, PA_2, 4800);
orSerial gps(PA_3, PA_2); gps.baud(4800);
…and now the debug doesn’t output anything
MichaelParticipantHi Mike,
Thanks for the quick response… actually I *am* trying to use the hard interface, since, as a hardware guy, it was clear the wires just weren’t there for the “soft”.However I thought I had compatible example code, but upon further inspection it warns against an overlap with the USB pins…so…
I don’t really know how to do what you suggested (Serial object).
Can you spoon feed me just a bit more?Thanks!
April 29, 2016 at 10:06 am in reply to: Centos: Dragging files to the Multitech Folder on the mDot #12354MichaelParticipantUnfortunately seems I don’t have permission on this machine
( thought I was a sudoer but I guess not )April 29, 2016 at 9:30 am in reply to: Centos: Dragging files to the Multitech Folder on the mDot #12353MichaelParticipant>>The USB drive is a staging ground to flash the processor on the mDot, it is not the mDot flash memory.
Ah, important distinction.
I’ll see if your incantation (or some variant) solves this issue for me.
Thanks!
MichaelParticipantIt seems I am now able to get into the unit via Web UI (after getting all the admin credentials and IP stuff squared away) so I started “from scratch” with my experimentation.
AT commands are OK now.
Moving on to “real code”.Not sure what (but I think I know “who”!) got the unit so hosed up to start with.
Thanks a lot.
Mike
MichaelParticipantOK, it’s wasn’t mentioned to hit enter. Besides, I had tried that, but the login opportunity vanishes quickly so I though it was not actually available.
(IOW it goes into that “Sending discover…” mode as I mentioned)So…I pressed enter and got:
mtcdt login:
and typing admin for both the login and password (quickly!) I received back:
admin@mtcdt:~#
However, again, the “Sending discover…” mode starts up.
Is that expected?(edit: OK, looks like you indicated that it is – even after logging in?)
MichaelParticipant>> Wait until you get a login prompt. Try to login with your credential and see if you are able to log in.
I never see a log-in prompt. Here’s what I get:
Setting up User-Space Watchdog _ _____ ____ / \ | ____| | _ \ / _ \ | _| | |_) | / ___ \ _ | |___ _ | __/_ /_/ \_\(_)|_____|(_)|_| (_) MultiTech Systems Application Execution Platform with mLinux GNU/Linux mLinux 3.1.0 mtcdt /dev/ttyS0 Version: 1.1.2 Date: 2016-01-13T09:59:04 mtcdt login: path ends at json object. increase depth or add --jsobj option udhcpc (v1.22.1) started Sending discover... Sending discover... Sending discover... Usage: /etc/udhcpc.d/lanup {bound|renew|deconfig} run-parts: /etc/udhcpc.d/lanup exited with code 1 No lease, failing udhcpc (v1.22.1) started Sending discover... Sending discover... Sending discover... . . .
The last few lines repeat over and over.
MichaelParticipantMichaelParticipantJeff,
Thanks for the clarification.
Might I suggest the page I referenced be made more complete by including your description?
b/r
MikeMichaelParticipantTerence,
If you look at my posts and the replies, apparently the eui is the device-specific ID.MichaelParticipantMy previous post has as example (00000037�) of what I’m talking about; you identified as some kind of leftover stuff. How would a user know it’s only leftovers?
If you are saying the output is generally easily readable, I’ll accept that and move on.
Thanks
MikeMichaelParticipantI was unable to find a “decoder ring” for the various fields in the “complete message object”. Some fields are rather obvious; others, not so much:
chan, cls, codr, datr, etc…
Thanks
Mike
April 11, 2016 at 3:13 pm in reply to: AT command bin file: one particular mDot acts differently… #12083MichaelParticipantThe unit was in that mode, 2, (I queried AT+NJM?) , but I did not issue the command.
MichaelParticipantThanks!
Is there a ‘c’ call I can make to extract s/n (EUI) within the mDot?
-Mike
MichaelParticipantAhmed,
I believe we are running similar environments.
I’m using Fedora and after r/r the power, the bin file does not appear when looking at the Multitech folder. (As you experience)
However, the mDot still has the file and will run it.
Mike
- This reply was modified 8 years, 1 month ago by Michael.
MichaelParticipantJ3 applies power to the Arduino connectors, but does not power the UDK2 board itself. The micro-USB supplies power to the UDK2.
MichaelParticipantMike,
Yes, and thanks.
Is there documentation for the library that would explain this kind of output?
Mike
- This reply was modified 8 years, 1 month ago by Michael.
MichaelParticipantJR,
Awesome, that worked!
Is there a place where this output
[INFO] entering sleep (stop) mode 00000037�
is explained?Thanks,
MikeApril 11, 2016 at 9:15 am in reply to: AT command bin file: one particular mDot acts differently… #12062MichaelParticipantHi BT,
No, I did not issue that command. At least not deliberately.
I will try to query the device should this happen again.b/r
Mike
April 5, 2016 at 9:37 am in reply to: AT command bin file: one particular mDot acts differently… #12022MichaelParticipantThat did it. I got “Command not found”, but control returned to the AT command set.
What was going on?
April 5, 2016 at 9:24 am in reply to: AT command bin file: one particular mDot acts differently… #12020MichaelParticipantOK, after a few minutes of playing with #3, it now acts like #2.
Why might this be?
-
AuthorPosts