|
Forum Index : Microcontroller and PC projects : MMX: GPS Function - bug, or help needed
| Author | Message | ||||
| BrantB Newbie Joined: 27/10/2017 Location: CanadaPosts: 40 |
Hello All, I am new(ish) to the Micromite ecosystem, but I am not a newbie programmer. First of all, I would like to express my admiration of, and thanks to, Geoff and Peter for their tireless work in advancing Micromite. Their effort is impressive ... as is the time and effort invested by some other regulars on TBS, who routinely chime in to help others - like me .I have had good success with the various facets of MM(X) that I have so far used for experimentation. However, I have run into a snag with the built-in GPS function, and I wonder if someone can either point out what I am doing wrong, or perhaps confirm that there may be a bug (?). Here is a bit of the usual "housekeeping", before I dive into the specifics of the problem: I am running MMX on a PIC32MZ2048EFH100 (not the 252MHz edition of the chip, so I am running at 200MHz). I have an ILI9341-based LCD hooked up in 16bit mode, and I am using the double-buffer driver (why not? ). As the subject line of this thread implies, I am focused on testing the GPS Function here - which, in my case, is aimed at COM3. My "OPTION LIST" is as follows:OPTION CPU 200 OPTION LCDPANEL ILI9341_16_BUFF, 98 OPTION HEARTBEAT ON Okay ... on to the specifics of the problem ... In short, I cannot seem to access any of the GPS parameters (using the built-in GPS function), even though I know there is valid NMEA data going to COM3. Actually, I fibbed; one parameter does work properly - GPS(VALID). It appears to accurately reflect the status of the NMEA sentences - but that's the only one which seems to work. All of the other parameters I have tried to access return a zero/default value, even when the VALID parameter shows a 1. Have I missed something here, in the way I should be using the GPS function? Or, have I unwittingly uncovered an issue? Here is a well-documented test program which demonstrates the issue. It basically just sets up COM3 for GPS, and then loops for 60 seconds, constantly displaying a series of current GPS parameters on the LCD screen. Pretty simple stuff. ' Simple GPS Test Program ' First, a detailed note about my LCD screen and some CONSTants in the code ... ' ' My IPS LCD screen appears to operate using an inverted display methodology. ' ' According to the ILI9341 datasheet, the controller has a pair of commands ' that determine the display's behaviour (i.e., inverted and non-inverted), ' which are as follows: ' ' 20h = Display Inversion OFF ' 21h = Display Inversion ON ' ' Unfortunately, I do not think there is a way in the MM language to issue ' commands directly to these types of intelligent LCD controllers. I tried ' the LCD CMD (and LCD DATA) directives, but did not meet with any success. ' I believe these are intended only for use with 1, 2, and 4 line text LCD ' displays. ' ' So, since there does not appear to be a way to interact directly with the ' ILI9341 controller, and since all of the colours on my IPS screen are ' inverted as a result, I had to develop a kludge. Namely, I define my own ' colour constants based on calculating the inversion of the colour I want. ' ' Without this explanation, I am sure the appearance of these constants in ' the code would be less-than-obvious :-). ' Define a number of common/useful colour constants for use with "inverted" ' ILI9341 display mode CONST MyBlue = RGB(0,0,128) XOR 16777215 CONST MyGreen = RGB(GREEN) XOR 16777215 CONST MyBlack = RGB(BLACK) XOR 16777215 CONST MyRed = RGB(RED) XOR 16777215 CONST MyCyan = RGB(CYAN) XOR 16777215 CONST MyWhite = RGB(WHITE) XOR 16777215 ' T is used to calculate a simple 1 second interval, based on TIMER DIM T as integer ' P is used as a loop counter for pulsing the LCD Backlight DIM P as INTEGER ' BL_PWM is used to hold the current LCD Backlight setting DIM BL_PWM as INTEGER ' GPS_PARAM$ is used to hold any given GPS Parameter (e.g., Lat, Long, ' Speed, etc.), as determined by the built-in GPS function. DIM GPS_PARAM$ AS STRING ' Ensure that the LCD is clear (black) CLS MyBlack ' Set the LCD colours to Green on Black COLOUR MyGreen, MyBlack ' We'll use the usual font, double-size FONT 1, 2 ' Turn on the LCD Backlight at full brilliance BL_PWM = 100 PWM 2, 250, BL_PWM ' Reset the TIMER, and calculate a 1 second interval. ' Then display the TIMER on the LCD, just as a sanity check. TIMER = 0 T = TIMER + 999 TEXT 0, 0+(MM.VRES*11/12), STR$(TIMER) ' The GPS module will (ultimately) be hooked up on COM3; so ' open/configure it for that purpose. OPEN "COM3:115200, 256" AS GPS, -5 ' The main loop is designed to run for 60 seconds. ' ' Inside the loop, the GPS function is referenced several times to ' extract various parameters, and display them on the LCD screen. DO ' If we are at a 1 second interval, calculate the next interval ' and show the current TIMER value on the LCD. This is just for ' sanity check purposes and amusement, as the loop is running. IF Timer > T THEN T = TIMER + 999 TEXT 0, 0+(MM.VRES*11/12), str$(TIMER) END IF ' Initially, I simply used the GPS function, buried directly in ' TEXT commands, to display values on the LCD - as follows: ' ' TEXT 0, 0+(MM.VRES*0/12), "GOOD:" + STR$(GPS(VALID)) + SPC(10) ' ' When the program did not generate expected results, I used a ' time-honoured troubleshooting technique by introducing an ' intermediate variable, and "simplifying" the syntax. Now, ' the result of any given GPS function call is first stuffed ' into a variable (GPS_PARAM$), and the corresponding TEXT call ' then simply references that variable. ' ' Unfortunately, this did not improve the situation. However, ' I have left it like that for now, until the issue is resolved ' (and then I plan on reverting to the "prettier" coding approach). ' Show the status of the GPS VALID parameter. (Note that the text ' label names have been shortened to 4 characters or less, so that ' everything will show on the LCD. After all, this is only a ' little test program.) GPS_PARAM$ = STR$(GPS(VALID)) TEXT 0, 0+(MM.VRES*0/12), "GOOD:" + GPS_PARAM$ + SPC(10) ' NOTE: At this point, a "real" program would only proceed if ' the GPS data was actually determined to be valid. However, ' for test purposes only, the balance of the GPS functions are ' called regardless. ' Show the status of the GPS DATE parameter. GPS_PARAM$ = GPS(DATE) TEXT 0, 0+(MM.VRES*2/12), "DATE:" + GPS_PARAM$ + SPC(10) ' Show the status of the GPS TIME parameter. GPS_PARAM$ = GPS(TIME) TEXT 0, 0+(MM.VRES*3/12), "TIME:" + GPS_PARAM$ + SPC(10) ' Show the status of the GPS LATITUDE parameter. GPS_PARAM$ = STR$(GPS(LATITUDE)) TEXT 0, 0+(MM.VRES*4/12), " LAT:" + GPS_PARAM$ + SPC(10) ' Show the status of the GPS LONGITUDE parameter. GPS_PARAM$ = STR$(GPS(LONGITUDE)) TEXT 0, 0+(MM.VRES*5/12), "LONG:" + GPS_PARAM$ + SPC(10) ' Show the status of the GPS TRACK parameter. GPS_PARAM$ = STR$(GPS(TRACK)) TEXT 0, 0+(MM.VRES*6/12), " DIR:" + GPS_PARAM$ + SPC(10) ' Show the status of the GPS SPEED parameter. GPS_PARAM$ = STR$(GPS(SPEED)) TEXT 0, 0+(MM.VRES*7/12), " SPD:" + GPS_PARAM$ + SPC(10) ' Show the status of the GPS (# OF) SATELLITES parameter. GPS_PARAM$ = STR$(GPS(SATELLITES)) TEXT 0, 0+(MM.VRES*9/12), "#SAT:" + GPS_PARAM$ + SPC(10) ' Continue looping until 60 seconds (60,000 ms) has elapsed. LOOP UNTIL TIMER > 60000 ' Close the GPS port; make sure we clean up after ourselves. CLOSE GPS ' Just a bit of foolish glitz and fanfare, here. We'll show a ' little "DONE!" status message (in white, on a red background) ' at the bottom of the LCD screen, and just to go over the top, ' we'll pulse the LCD Backlight 3 times, too. TEXT MM.HRes/2, 0+(MM.VRES*11/12), " DONE! ", "CM", 1, 2, MyWhite, MyRed PAUSE 500 FOR P = 1 TO 3 FOR BL_PWM = 100 TO 20 STEP -1 PWM 2, 250, BL_PWM PAUSE 4 NEXT BL_PWM FOR BL_PWM = 20 TO 100 PWM 2, 250, BL_PWM PAUSE 4 NEXT BL_PWM NEXT P ' The LCD Backlight should already be up at 100% by this point, but ' it does not hurt to be paranoid. Let's make sure the LCD Backlight ' really is up at full brilliance when we end the program. BL_PWM = 100 PWM 2, 250, BL_PWM ' That's it, that's all :-). END Attached ( 2018-03-04_065635_GPS_Test_Data.zip ), are a couple of text files (containing previously captured NMEA strings) that I pump into COM3, using RealTerm, for test purposes. (Yes, I have already verified - with another simple test program - that COM3 is connected properly, and that it can communicate successfully in each direction with RealTerm, at 115.2K baud. So, all is good there.) In the case of the "Stockholm.txt" file, all of the sentences should compute to be valid. Indeed, the GPS function yields a steady "GOOD:1" result on the LCD screen. In the case of the "ValidTest.txt" file, the data stream starts off with a series of no-fix RMC sentences, followed by a series of valid-fix RMC sentences. Sure enough, the GPS function at first yields a steady "GOOD:0" result on the LCD screen, and then it flips over to a steady "GOOD:1" result. However, regardless of whether the GPS(VALID) parameter is 1 or 0, the following reflects the GPS results which are consistently shown on the LCD: DATE:00-00-2000 TIME:00:00:00 LAT:0 LONG:0 DIR:0 SPD:0 #SAT:0 If any of you have any insight you would care to share, it would be much appreciated. Peter- if you happen to read this ... and if this does turn out to be a bug ... and if you happen to jump into your code to squish it ... could I make a request/suggestion? It would be quite useful to be able to distinguish the difference between a "no valid data" condition, and a "no data" condition (as in, a complete loss of connection with the GPS module, due to a broken cable, fried unit, etc.). How would you feel about having GPS(VALID) return a -1 (or a 2, or something else of your choosing) when there is no data stream detected at all on the GPS port? Alternatively, a new GPS(ACTIVE) or GPS(CONNECTED) element could be added, if you would rather not mess with the existing (VALID) functionality. I recognize that (VALID) already reverts back to 0 when there is no data stream (I get the impression that happens after one second; maybe two). But (VALID) = 0, on its own, is ambiguous in this context - it could just mean a temporary loss of satellite signal (i.e., while in a concrete canyon, tunnel, etc.), or it could mean an entire loss of the data stream (i.e., total disconnection). Perhaps the "no connection" detection could/should be more forgiving (?) - maybe kicking in after 5 or 10 seconds of silence. Cheers! Brant |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10569 |
Will look properly tomorrow but try getting rid of the ",256" |
||||
| BrantB Newbie Joined: 27/10/2017 Location: CanadaPosts: 40 |
Thanks for the prompt reply! (especially since it is your bedtime) I gave that a go, but no joy. While I was at it, I also tried getting rid of the -5 timezone offset, and that didn't help either. One (other) thing I have noticed, is that sometimes (many times, actually), the last character of GPS(DATE) and GPS(TIME) will be truncated. I have not yet managed to isolate the exact circumstances when it works properly, and when it doesn't .So far, it looks like that fate is determined during the flashing of the program (but that doesn't make any sense). I say that, because multiple "RUN"s of any given program have always yielded consistent results (i.e., either consistently good, with no truncated output, or consistently bad, with the final character missing). For what it is worth, I added a PRINT line to send a separate GPS(DATE) reference to the Console, and the truncated issue shows up on the console, too. So, it has nothing to do with the LCD TEXT commands. In fact, to my surprise, the Console shows "00-00-200 000:00:0" for GPS(DATE). I didn't expect the DATE parameter to have the time element, too. I hope you get(/got) a good night's sleep .Cheers, Brant |
||||
| lew247 Guru Joined: 23/12/2015 Location: United KingdomPosts: 1702 |
[quote]In the case of the "ValidTest.txt" file, the data stream starts off with a series of no-fix RMC sentences, followed by a series of valid-fix RMC sentences.[/quote] What GPS unit do you have? I have one of the new neo-M8N ones which can receive Galileo as well as the other satellites The sentence has changed very slightly and this might be why it's not working? I have to use "GNRMC" instead of "GPRMC" to get my gps code to work [quote]The first 2 letters after the $ sign in the NMEA message is the Talker ID and indicates the nature and source of infomration: GP: GPS; GL: Glonass; GA: Gallileo; GN: combinded GNSS systems. [/quote] |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10569 |
This is a bug that I, with the compilers help, introduced in V5.4.13. The compiler gives warnings when you set a variable but don't then make any use of it. The idea is to get rid of redundant code. Unfortunately it looks like it also does this sometimes when you do make use of the variable in a somewhat obscure way. In 5.4.13 I did a big tidy up to get rid of all compiler warnings and it looks like I got suckered by one or more in the GPS code. I'll post a bug fix release later today. Bug fix here |
||||
goc30![]() Guru Joined: 12/04/2017 Location: FrancePosts: 435 |
For information by storing my drawers, I just found a card "explorer16" and as I had a PIM pic32mz2048efh100, I tested mmbasic. first problem: connect the pin 86 of the chip with the pin 88 of the PIM (rx console). it work correctly. I can blinking a led (big program) second problème is to use TFT 16bits: on the board pins "RB" are used (i can disconnect pot input) to continue... |
||||
| BrantB Newbie Joined: 27/10/2017 Location: CanadaPosts: 40 |
@matherp - Wow! Thanks very much for the prompt investigation and bug fix. I am, unfortunately, away from my setup today. But I am eagerly looking forward to applying the update and seeing it in action (both the GPS and the PWM) tomorrow. Cheers! @goc30 ... As a newbie to the forum, it makes me feel good to be able to make a contribution already. I have the very setup you are describing, and discovered the same Console RX issue you did. I was in touch with Microchip Support about it, and they confirmed that it has been a known issue (internally) for some time. Even so, they never did correct the missing trace on the PIM (nor did I get the impression they have any plans to ever do so ).I am not well equipped to deal with fine/SMD work (at least, not yet), and I could not for the life of me find a local service shop to take on the task for less than two arms and two legs. So, I was forced to abandon the idea of using MMX for that part of the project. Recently, I dusted off the setup, because I managed to find someone to do the fine work on the PIM. I didn't have any trouble hooking up my LCD in 16bit mode to the Explorer/PIM rig (I didn't have to desolder anything) - so I am wondering what you might be doing differently to me. What is the "RB" pin that you are referring to? Is this on your Explorer board, or is it in reference to MMX predefined signals? FWIW, here are the pin assignments I used for hooking up my LCD in 16bit mode: LCD_BACKLIGHT = J48 Pin 4 (P29) - for PWM LCD_D5 = J46 Pin 46 (P20_POT) LCD_D4 = J46 Pin 45 (P21_TEMP) LCD_D3 = J46 Pin 48 (P22) LCD_D2 = J46 Pin 47 (P23_CSB) LCD_D1 = J46 Pin 50 (P24_ANB) LCD_D0 = J46 Pin 49 (P25_ANA_USBOC) LCD_D6 = J48 Pin 1 (P26_PGC_E) LCD_D7 = J48 Pin 2 (P27_PGD_E) LCD_D8 = J48 Pin 17 (P42) LCD_D9 = J48 Pin 3 (P28) LCD_D10 = J48 Pin 9 (P34) LCD_D11 = J46 Pin 2 (P76) LCD_D12 = J48 Pin 16 (P41) LCD_D13 = J46 Pin 1 (P77) LCD_D14 = J48 Pin 18 (P43) LCD_D15 = J48 Pin 19 (P44_LCDRS) LCD_RESET = J46 Pin 21 (P97) LCD_RS = J46 Pin 22 (P96_VBUSON) LCD_WR = J48 Pin 43 (P68) LCD_RD = J46 Pin 24 (P98_LCDD2) - specify CPU pin 98 in OPTION LCDPANEL The Net names in brackets, above, refer to those on the Explorer16 schematic. And, I split up the list above, where ever the connection pattern flips from J48 to J46 (or back to J48) ... in an effort to make it slightly easier to follow when you're in the midst of wiring things up. One other thing I can definitely warn you about, is that MMX's SPI2-IN will be unavailable to you, unless you want to do more desoldering on your Explorer16 board. The corresponding CPU pin only makes it as far as one side of the on-board 32KHz circuit ... and some fiddling is required to get it bridged all the way through to J48 Pin 48 (P73_SOSCI_E). There may be other gotchas awaiting me/us - but that's what I can contribute so far. Hope that helps a bit. Cheers, Brant |
||||
| BrantB Newbie Joined: 27/10/2017 Location: CanadaPosts: 40 |
It is a US GlobalSat unit. (Sorry - I am away from my rig today, so you will have to wait for the specific model, if it is important to you.) You make a good point about the NMEA prefixes. Though I had not thought about them in this case, I am aware of them from another project, with a different GPS unit (also based on uBlox, though). In this particular case, both sets of data used the "normal" GP prefix, so I didn't think that would be the issue. Oh, I see what you're saying now ... maybe GP would not work, but GN would. Got it. (You gotta get up early to fool me .) As we now know (from Team Mather's speedy response), the issue with the GPS function turned out to be a legitimate bug, and not related to the prefixes. But thanks for the suggestion . In retrospect, since the (VALID) parameter flipped from 0 to 1 when expected to do so, indications were that the sentences were probably okay. When I am back in front of my rig tomorrow, I fully intend to set up some (more) tests to see how Peter's GPS function behaves with various combinations of sentences (i.e., just RMC, the more usual combination of suspects, different prefixes, etc.). I will come back and let you know what the results are when the testing is complete. Cheers, Brant |
||||
goc30![]() Guru Joined: 12/04/2017 Location: FrancePosts: 435 |
I have not tried to connect the screen yet, because I wanted to keep leds, buttons and sensors (for my tests), if possible ![]() So I will continue my tests points by points the pins "RB" as you say, these are the Pic's pins name(rb0-rb15) for the connection "rx", I put 3 hours with a microscope, a solder very fine and .. a beginning of parkinson |
||||
| BrantB Newbie Joined: 27/10/2017 Location: CanadaPosts: 40 |
We are kindred souls. I spent a day with a magnifying visor, solder paste, flux paste, a (comparatively) large soldering iron, and some solder wick (de-soldering braid), putting a 50-pin 0.5mm pitch FPC connector onto a breakout board so that I could hook up my LCD panel (which is a "raw" unit, without a backer PCB). I succeeded in the end, but my wife still can't understand why I have this nervous tw-tw-twitch now. Like you, I would really rather not muck up my Explorer board. So, in my case, now that I have discovered the SPI2 incompatibility, my intention is to use SPI1 for an SD card. (That is next on my list, right after I finish off my GPS tests.) Luckily, Peter has made provision in MMX for choosing which SPI channel is used. Thanks (again), Peter. (I think I am going to end up saying that a lot, as many others have .)Good luck with your tests. I will be happy to share whatever I discover, too. Hopefully my wiring guide will allow you to implement your LCD without any headaches. |
||||
goc30![]() Guru Joined: 12/04/2017 Location: FrancePosts: 435 |
thank you for all informations that will be very useful. I will use this card especially for audio, if possible (spi ??) I will put the test results on this forum thank for your guide , i save time |
||||
| BrantB Newbie Joined: 27/10/2017 Location: CanadaPosts: 40 |
You are most welcome. As I said, I am pleased to be able to contribute something. I would not want to feel like a leach. You mention audio, and SPI. Is that really want you meant, or did you actually mean I2S? I ask because audio is on my too ... right after I finish experimenting with and testing the GPS function, and after I implement an SD Card (on SPI1). In my case, the audio implementation will involve I2S - to a pHAT DAC module (still have to work out the pinouts) - for FLAC playback. So ... if it is I2S you are going to work on, then I can hardly wait to read about your experience. If you really are going to do it by SPI, it will still be interesting to follow along (for some future endeavour) - but I won't be drooling to the same extent as I await your reports .I guess, with all due reverence to the Gods of Organisation (and for greatest benefit to others), discussion of audio should really go in another thread when the time comes. |
||||
goc30![]() Guru Joined: 12/04/2017 Location: FrancePosts: 435 |
yes i need to connect sommes audios cards in I2S In fact, i want to make a system who can multiplex some differents audio sources like radio walky-talky, smartphone, pc (ac97), phones (classiques) and local intercom. I have make analogic system mixed with some digitals), but i want to work only in digital multiplexing. I understand that it's not easy and I enjoy to accept your help. actually i work with wolfson chips (wm9712) Its a good idea to create an audio thread here |
||||
| BrantB Newbie Joined: 27/10/2017 Location: CanadaPosts: 40 |
@matherp, I hate to say it, but the updated firmware does not appear to have made any improvement to the (mis)behaviour of the GPS function. I still get exactly the same behaviour as I saw, initially. This includes being able to see the (VALID) parameter go from 0 to 1 when expected to do so (i.e., using my ValidTest.txt data stream) - but other than that, the rest of the parameters all return 0/default values when using either the "ValidTest.txt" data stream, or the "Stockholm.txt" data stream. Also, I continue to experience the intermittent truncation of the final character for both the (DATE) and (TIME) parameters. So far, just in a dozen or so runs today, I have seen the non-truncated results a couple of times. Mostly, the system has returned the truncated versions. I am still at a loss to explain what causes that. Mind you, if the issues with the GPS function have something to do with obscure variable references and compiler internals, then it may be a pointless exercise for me to try to correlate a cause anyway. I can chase other wild (Canadian) geese just as easily. ![]() Lastly - what is normal/expected behaviour for the (DATE) parameter? When working properly, would it return the date and time component combined, or should it only return the date component? (I would think, the latter.) I ask, because it continues to return both elements combined - and when the truncation issue is present, both elements are truncated with the (DATE) parameter on its own. Cheers! |
||||
| BrantB Newbie Joined: 27/10/2017 Location: CanadaPosts: 40 |
@matherp, ![]() I take it all back! The firmware update is fine. I somehow screwed up .There is a very good reason I saw exactly the same behaviour. It is because I ended up re-burning exactly the same firmware (sigh). I wanted to keep the original version of the 5.4.14 hex file, just in case I needed to do further (comparative) troubleshooting. So, I created a copy with a new name. And after that, something went screwy - it looks like I somehow might have re-downloaded the earlier version of the ZIP file from the forum, instead of the correct/new one. Of course, since the version number didn't actually change, I was doomed. Anyway, I am very pleased to report that the error was mine, not yours, Peter. (Well, it does not please me that I goofed up like that , but I am glad it turned out to be something so simple.)Anyone: This brings me to another question (about using the forum) - how do I edit my own messages? I see that others do it, and I have looked at the Help (which, in this case, is not helpful). I don't see an Edit button anywhere. I would like to edit my previous "no joy" message with a line at the top, to warn future readers that the information contained therein is not accurate. I don't want to erase my gaffe - there is no integrity in that. I did it; I will "own" it. But, I don't want to cause people grief with bad information. BTW - I will be cross-posting this reply to my other (PWM) thread, as well, since the info/outcome is all relevant there, too. |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2959 |
Once you post a message, the EDIT feature exists UNTIL someone else posts . . . . As soon as another person posts, the EDIT button disappears! Try it and you should see it . .. EDIT - the EDIT button is at the 'end' of all the buttons on your 'last' post EDIT2 - after the 'Buddy' button ! |
||||
| The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |