GPS update rate Raspberry pi Jessie Vs. Wheezy - gps

I have scoured the internet to this problem and am unable to find any kind of answer. Here is the gist of the project and what I have done so far
Project: Our school participates in sounding rocket competitions. I am in charge of payload and part of our payload includes GPS. Our rocket goes up to 2 miles and does not break the sound barrier
GPS module: Adafruit ultime GPS breakout
Raspberry Pi Model: B+ or 2 (we have access to both)
Problem: Since the rocket travels very quickly (arroximately 700-800 ft/s) we need the GPS to update at a faster rate than once per second (default rate). I have 2 raspberry pi's that both use GPSD daemon, and a personal python script. The problem lies within: With debian Wheezy, I can set the update rate from the bash with the following commands
"echo -e "\$PMTK251,57600*2C\r\n" > /dev/ttyUSB0" - updates baudrate
"echo -e "\$PMTK220,200*2C\r\n" > /dev/ttyUSB0" - updates NMEA sentences
"stty -F /dev/ttyUSB0 57600 clocal cread cs8 -cstopb -parenb" - updates baudrate of raspberry pi
On debian Wheezy these commands work and I get GPS coordinates at a rate of 5 times per second. - no problem.
The other pi uses Debian Jessie, which when I run the exact commands they do not work and the GPS unit continues to update at its default rate of once per second.
I am very confused as to why it will work on Wheezy but on Jessie it refuses to cooperate.
Some additional info:
- We communicate over USB0, (not AMA0)
- Jessie natively does not support GPS functions and one has to manually change how to listen to GPS chips (wheezy natively supports this and no changes are necessary),
- we are using full Jessie (not lite).
- When I change the baud rate of the Pi Jessie, and I follow up to see what its set at (using: stty -F /dev/ttyUSB0 -a) it tells me the baud rate is whatever the new value i gave it (i.e./ 57600).
So i believe the problem lies with setting the actual GPS units baud rate/NMEA sentencing
I think I have included all pertinent information but if I left something out I apologize and can clarify anything that isn't clear enough.
Any help would be greatly appreciated since we would like to upgrade to Jessie (other chips and programs that we incorporate on the sounding rocket run smoother with Jessie) but the GPS is a major reason not to.

I realize that this is an old thread, but since I ran into the same problem I will post my solution so that it possibly may help someone else.
I have a Raspberry 3 B+ running Raspbian Stretch, Adafruit Ultimate GPS attached to ttyAMA0. For RPi3 the bluetooth module needs to be disabled by adding the following line to /boot/config.txt:
dtoverlay=pi3-disable-bt
Anyway, I have previously been able to program the GPS module by echo commands, as described above. However, no success this time. Finally I managed to program it by installing the terminal program CuteCom.
Start the program, change the baud rate under settings, and press Open. The NMEA sentences should then appear in the lower part of the window. Make sure that the line end termination is set to CR/LF, and give the input command directly without hyphens or line terminations. For example to change the baud rate to 57600 write:
$PMTK251,57600*2C
The connection then have to be closed, the baud rate changed accordingly and then opened again. I noticed that sometimes the command needs to be repeated before the change takes place. If the backup battery is installed on the GPS module the settings are kept when power is lost.

Related

STM32 Virtual COM Port appears as Device in DFU Mode on Windows 10

So, my knowladge in embedded development is quite bad and now I am trying to receive some data from PC inside my MCu STM32F429IGT6 which is on WaveShare Core4X9I dev-board and send it back via USB Virtual COM Port.
I realized how to set up connection from MCu part and I even see connected device from Windows 10 Device Manager but... it appears as STM Device in DFU Mode
I have tryed already to install drivers from ST for such things but they are useless and official documentation says that they are not needed for Windows 10.
I have been following tutorials where guys just clicked several times inside Cube MX, generated code and VCP worked out of the box.
The question is what am I doing wrong? I don`t even know what information you might ask for thats why I created GitHub repo: https://github.com/dessy4oko/stm32f429-vcp-appears-as-dfu
And this is events from Device Manager of Windows 10 (translation from ru lang):
Device USB\VID_0483&PID_DF11\305233703237 is running. code 410
Device USB\VID_0483&PID_DF11\305233703237 is configured. code 400
Device USB\VID_0483&PID_DF11\305233703237 have not been moved due to partial or ambiguous matching. code 442
Device USB\VID_0483&PID_DF11\305233703237 requires further installation. code 430
Thank you for any information about my mistakes.
STM32 starts in DFU mode if BOOT-pins are pulled accordingly:
"System memory" means embedded bootloader, DFU in this case. You need "Main Flash" to run your app.
Check jumpers and switches on your board. Refer also to the AN2606 app note for complete information.

Headless Setup of Asus Tinker Board S

I am trying to set up Tinker Board headlessly as I don't have access to a wired keyboard and mouse.
One method I know that works for Raspi is by creating an SSH file while setting it up and a wpa_supplicant.conf file to provide wifi details. I have flashed the latest Tinker OS v2.2.9 onto the eMMC present on the board as per the instructions. But, in this case I am not able to access the drive once flashed (Contrary to raspi setup).
Is there a way to set it up headlessly?
Thank you for taking out time to read this and helping out.

Connecting to tty port through C++ fails unless you've connected through screen first

I picked up an AUPS-A10-R11 DC UPS, and am working with their API to build some monitoring software for my xen host. Their API runs over the USB connection on the device, which presents itself as /dev/ttyUSB# on the host.
I've got things working fine except for one thing that's puzzling me. When I first power on or reboot the host it's connected to, I can't communicate with the device. However, if I open up a screen connection to it:
screen /dev/ttyUSB0 9600
and then close it (ctrl+a, k) then it will work perfectly fine until the next time that you reboot the host.
Does anyone have any idea as to why I would have to connect to the device over screen first? I've pasted my code here: http://susepaste.org/0b8bb37f . When connecting on a fresh reboot, it stops at the "Read Nothing" section of the if...else clause. After connecting to the device with screen, it works fine.
Any thoughts??
Does anyone have any idea as to why I would have to connect to the device over screen first?
Such behavior is almost always related to incomplete termios initialization by your program.
The ideal program would configure a serial terminal for its purposes, and on exit restore the termios configuration back to the way it found it.
But most programs, including terminal emulation programs such as minicom and apparently screen, simply leave their termios configuration instead of restoring it.
Fortunately for you, this leftover termios configuration fills in the missing pieces that allows your program to access the serial terminal as expected.
Review of "your" code suggests that it was copied from the accepted answer of this question. Based on the number of up-votes, this code apparently works for a lot of people. However the author admits it was written before POSIX standards, and therefore the code should not be considered portable. In other words, your mileage may vary.
Apparently you overlooked the alternative answer which is POSIX compliant. A tested termios configuration for blocking non-canonical mode is in that program.
If you prefer to simplify with the use of the cfmakeraw() macro, then here's another code example.

Chromium on Raspberry Pi breaking keyboard input

I have a couple of older printers (a Brother and an HP all-in-one) that I want to run as wireless and cloud-based printers. To do so, I bought a Raspberry Pi 2 and set it up as a headless print server following some online tutorials. Both of the printers are accessible wirelessly from my home network, but because my primary computer is a Chromebook and I use Android phones and tablets, the only good way I've found to print to them is using Google Cloud Print.
To do this, I downloaded Chromium onto the Raspberry Pi and signed in using my gmail account. This kind of worked for a few months, but the cloud connection would go down after a few days and I'd have to reboot the Raspberry Pi to get it back (there was probably a better way, but, since it was headless, it just seemed easier to reboot).
Eventually, I got tired of rebooting the Raspberry Pi and I read something on the Internet about upgrading my software to get new versions of the OS and of Chromium. Unfortunately, since doing so, I've been having problems.
Since I'm running headless, my primary means of connecting are via ssh and vnc connections from my Chromebook. ssh is fine, but I can't run Chromium on the Raspberry Pi via ssh (at one time, I found a tutorial on how to do this, but it has since been taken down and I think Google nixed the support for that somewhere along the line).
To start Chromium, I log with a vnc connection. When I log on the first time after a reboot (or after restarting the vnc server), everything works fine. I can use, for instance, the word processor or terminal available through the GUI. All is well. However, if I start Chromium, all of the sudden nothing will accept keyboard input. It is almost as if there is no keyboard connected at all at this point. Mouse input still works fine and I can open and close programs to my heart's content. Closing Chromium doesn't fix the problem. Closing the vnc connection from the client and logging back in doesn't fix the problem. Restarting the vnc server does fix it until I start Chromium again.
I say "almost" above because, even though pressing keys on the keyboard don't appear to do anything, the cursor (especially visible in the terminal window) does flicker with each key press as it would if I were typing actual text.
I've searched for this issue on Google, but my search has turned up very little. There were some lubuntu posts about possibly not using ibus, but, from what I can tell, that is not relevant to my situation. At least, I couldn't find anything ibus in ps and I couldn't find any options in the GUI preferences.
My Raspberry Pi is running what I believe is the latest version of Raspbian (I updated/upgraded again last night to be sure):
pi#raspberrypi:~ $ uname -a
Linux raspberrypi 4.4.21-v7+ #911 SMP Thu Sep 15 14:22:38 BST 2016 armv7l GNU/Linux
pi#raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
It's running TightVNC with the following command-line options:
pi#raspberrypi:~ $ ps aux | grep vnc
pi 13537 0.0 2.2 91556 22584 ? S 01:05 0:27 Xtightvnc :1 -desktop X -auth /home/pi/.Xauthority -geometry 1368x768 -depth 24 -rfbwait 120000 -rfbauth /home/pi/.vnc/passwd -rfbport 5901 -fp /usr/share/fonts/X11/misc/,/usr/share/fonts/X11/Type1/,/usr/share/fonts/X11/75dpi/,/usr/share/fonts/X11/100dpi/ -co /etc/X11/rgb
Chromium's chrome://help About section says "Version 51.0.2704.91 Built on Ubuntu 14.04, running on Raspbian 8.0".
Beyond that, I don't know what other software/versions would be relevant, but if anyone can think of anything else that would be helpful, I can update this description.
Through trial and error, I've discovered that the Chromium keyboard/RDP issue seems to be related to particular extensions on my profile.
To verify this, try running Chromium with --disable-extensions.
The particular extensions/apps I've found to be problematic are:
Google Play Music
Plex
As soon as I disable these, keyboard starts working again. Does this help?
I'm running the 4.4.38 version of Raspberry Pi 3, which is the newest, and the newest chromium-browser (v.51). Although I am using a mouse and screen, I'm getting keyboard error messages, and other messages, and browser is hanging in some cases. I pretty quickly see the following errors on console after starting chromium:
[2530:2530:0217/142822:ERROR:sandbox_linux.cc(334)] InitializeSandbox() called with multiple threads in process gpu-process
[75:75:0217/142957:ERROR:PlatformKeyboardEvent.cpp(117)] Not implemented reached in static PlatformEvent::Modifiers blink::PlatformKeyboardEvent::getCurrentModifierState()
After asking on the raspberrypi.org forum, it was suggested that I wait for the next version of Chromium. It looks pretty sure that there is an i/o error between mouse and keyboard controls and chromium, and appears quite similar to your issue.
(I do not have the necessary 50 points, so I cannot comment, only as a solution, which in this case is not true, since I also did not find it yet.)
I have the exact same problem with a Pi 3, but in my case when remotely connected with xrdp (w/ Windows Remote Desktop).
I believe the symptoms appeared after an update-upgrade session. My current version:
pi#raspberrypi:~ $ uname -a
Linux raspberrypi 4.4.38-v7+ #938 SMP Thu Dec 15 15:22:21 GMT 2016 armv7l GNU/Linux
I originally only wanted to change the keyboard-layout to German, and from what I understood until now is that through xrdp it is not possible, unless you define your keyboard layout completely manually, see:
http://forums.fedoraforum.org/showthread.php?t=265100
http://cloclotron.net/xrdp_keyboard_layout_workaround.html
As soon as I open Chromium, I see the same behaviour as you, if I close it, everything is back to normal. If working on a directly connected monitor with kexboard plugged in, I experience no problems.

SMSC911x network interface cards' light never comes back on after cable replugged

I have this strange problem in an embedded system (linux) we build, so I don't have normal GUI trouble-shooting tools on Linux or Windows machines.
The problem is the NIC is no longer usable after cable removed. Even if I re-plug the cable, the lights on it never come back on again and nothing can be sent or received. ifconfig still works on the surface, but doesn't have real effect. Only a reboot will solve the problem. I guess the problem is in the ethernet driver.
My question is how the trouble-shoot it. Any clues/hints? Thanks.
====================
Thank you guys! The board is a gumstix and the PHY is SMSC911x. We are running on Linux 3.0.12. It turns out the smsc911x_soft_reset() of the NIC fails when driver calls smsc911x_open(). The symptom also includes we must run ifconfig multiple times (not consistent) to bring the NIC up and the system can detect it.
I did a search on "SMSC911x soft reset failed" and find this link. http://comments.gmane.org/gmane.linux.network/216467. I removed SMSC_PHY=y in the linux build config file and that fixed the problem. It seems the driver is not compatible. Can somebody explain this, or is there a better solution?