I'm trying to get a Raspberry Pi with a 4" touch screen setup to wardrive and capture some WiFi signals. The piece that is giving me issues is getting the GPS working.
I'm trying to use a module that came with Microsoft Streets & Trips I got a long time ago.
lsusb shows the device as "Bus 001 Device 007: ID 1546:01a5 U-Blox AG [u-blox 5]"
dmesg | grep tty shows:
[ 8.276615] cdc_acm 1-1.1:1.0: ttyACM0: USB ACM device
[ 344.931792] cdc_acm 1-1.1:1.0: ttyACM0: USB ACM device
I do see a data stream if I issue cat /dev/ttyACM0
sudo gpsd /dev/ttyACM0 -F /var/run/gpsd.sock and then gpsmon /dev/ttyACM0 gives the following:
But then when I try cgps -s I get:
I seem to be getting some data but no lat/long/time data.
Should I conclude that this GPS module is not supported?
Are you sure your receiver has a satellite fix? Also, you have a log of the GPS data stream? Do you know what specific model receiver you are using?
From your first screenshot it looks like you are definitely receiving data from the GPS, as it's recognizing several different NMEA sentences. On top of that, the first screenshot shows what seems to be a valid GPGLL sentence (I haven't confirmed the checksum):
$GPGLL,,,,,224538.00,V,N*40
My initial hunch would be that the GPS receiver does not have a satellite fix. This is based on
Empty GPGLL sentence. The only populated fields in the above sentence are the UTC time and Status fields. The Status value is V, which means the data is invalid.
Status NO FIX in the second screenshot.
The various boxes in the first screenshot give me the impression that GPSD is correctly parsing the various NMEA packets. For example, the GSV box lists various satellites in view.
The lsusb output reports the device as a u-blox receiver. U-blox receivers generally have solid support from GPSD, so I'd be surprised if this receiver isn't supported (but anything is possible). Without knowing the specific model it's hard to say anything definitive.
I've only worked with a couple different receivers, but my general experience is that when they don't have a fix on startup they'll send empty/partial packets. And the date/time data in those packets is probably due to a Real-time clock (RTC) on the receiver. RTCs are common on GPS receivers as they often drastically improve the Time To First Fix (TTFF). So it makes sense that you have a time, but it's marked as invalid.
Recommendations
The fact that your receiver is reporting satellites in view (though none are being used) and that the Status is NO FIX is especially strong evidence to me that your receiver probably just doesn't have a fix. Try moving it to somewhere with a better view of the sky. Also ensure that if it requires any kind of external antenna hardware that you connect that. Lastly, you might have to wait awhile to get a fix. If it's been awhile since you've used the device you could be looking at a cold start with a TTFF of upwards of 10-20 minutes.
Related
I am trying to make some custom firmware for a MIDI controller (AKAI LPD8).
There is an STM32F102R8T6 chip in the unit.
I am trying to reach it with a programmer to wipe it, but it seems to not be responsive.
Some information and thing I have tried:
The firmware that came with the unit works, so the chip is not broken
Removed the components connected to the programming pins (PA9-PA10 and PA13-PA14)
I am able to pull BOOT0 high and have it not run the main program, but I am however not able to get a life sign using either an ST-Link2(clone) connected to PA13/14, nor a USB to serial adapter connected to PA9/PA10, so I am not sure what mode it is in
The connection has been checked, and RX-TX etc is the correct way around (but also for the sake of trying it all, I reversed the connections as well...).
Tried both the STM32CubeProgrammer and stm32flash, but none connects.
I am actually not sure if AKAI have locked the chip in such a way that you cannot even do a full chip erase and use the chip for something new? The NRST pin is strangely not doing anything to the running of the firmware either when I try to pull it low.
Is there a way to reprogram these chips when they come off of a commercial product, or are they permanently locked?
Any solution/tips?
Many of the STM32 parts have "proprietary code read-out protection" (google PCROP) which but you might be lucky and they haven't enabled it in the option bytes. Read the documentation for that and the bootloader documentation and get a good idea of what you expect it to do if it is enabled and if it isn't.
If you have a scope, try watching the SWD/JTAG pins to see if there is any response from the device. (If you aren't even sure if it is in reset then scope the crystal if there is one).
If you haven't got a scope, you might be able to to verify what it is doing by seeing if it sets the pins and pull-resistors to how they would be expected to be in the bootloader mode, eg: UART TX should be high if it is enabled, even it it isn't transmitting anything. Put a strong pull-down (~1k) on there and see if it still reads high.
After hours of trying different ways of making it work (also tried the alternate mapping of the UART port), and probed the TX pin as suggested by Tom V to no avail, I have given up working on that specific chip and ordered an upgrade from the STM32F4 family instead to replace it with. A lot more power and useful peripherals.
A bit of a non-answer to the specific question. Frustrating to not have found out what was wrong (chip or approach) but being mindful of the sunk cost fallacy, I think it was best to just replace the chip with a fresh one and start development from there.
I'm having trouble with i2c communication. In my i2c bus, i have 4 boards (STM32L4 Sensortiles) and sometimes one of them blocks the bus and the others stop communicating consequently. When I reset that one that blocks the bus, all boards starting working again.
In my debugs, this bug happened when HAL_I2C_GetState(&hi2c3) returns HAL_I2C_STATE_BUSY_RX, even my others i2c functions HAL_I2C_Slave_Receive_IT and HAL_I2C_Slave_Transmit_IT returns HAL_OK:
Any ideas what Im doing wrong? Thanks.
Using libraries like HAL leads to problems like this one. Why?
HAL users feel free from knowing your hardware as magic library will do everything for you.
HAL users usually do not know how the peripheral works and how to debug it.
HAL users do not bother to go through the magic HAL function to see what the problem is.
Posting some images form debugger will not help.
What you need to do:
Get even the cheapest logic analyzer (there are $10 on ebay) and record the communication. See if the slave keeps the clock or data line low. If yes toggle the clock pin 9 times to unblock the line
If nothing helps reset the I2C peripheral using RCC register (it has to be implemented on all connected boards).
My first question on here so I'm not sure if that's the right forum.
I've connected with my car's ECU K-Line through FTDI-OBD cable and terminal. Found it's something like KWP2000 but without preinit hassle. I just send it commands on 9600 baud, even parity, 1 bit stop and got a reply with VIN number. When I try to send same command with ELM327 it doesn't work and I believe because of ELM adding something, either initialisation of the KWP or adding some checksum or additional info and it doesn't work.
I've already tried using
ATSP5
ATIB96
ATBI
And it still doesn't respond eg. VIN message from sending same command.
My point is to get to secret sensors data from $21 because there is a little info in regular Mode01. And I want to use ELM327 because I wanted to use Android phone to display the data.
I have used the raspberry pi to detect the ibeacons and gone through the tutorial provided by Radius Networks here. I made a small script that first turns on lescan and redirects output to /dev/null. Then it turns the hcidump on piping to the output to the script.
The output shown by the script is slow. While the advertisement packets are transmitted in magnitude of milliseconds, the result however on the terminal is slow. consequently, the command keeps on showing new output even if you turn off the transmitter. My understanding tells me that parsing takes its time, while the HCIDUMP data waits in the sed queue.
For proper action to trigger according to proximity, minimum parsing time is necessary so that all packets are parsed as they are received.
Have i missed something or parsing is faster if one uses the bluetooth development kit provided by Radius Networks? if so, what makes it faster?
Thanks,
You are correct, the output of the script does lag behind when detecting a large magnitude of iBeacon advertisements. The parsing script was written in bash for simplicity, and its speed suffers as a result -- piping to sed to store each identifier is slow and inefficient. The script was rewritten in Ruby for the Beacon Development Kit (now called the PiBeacon) and is much faster and more responsive. Ruby and other high-level level programming languages are more well suited for parsing and converting the raw iBeacon packet data. A disk image of the development kit with this new script is available to download here.
You can also try implementing another iBeacon Raspberry Pi scanning script, written in Python, that can be found here. I have yet to try this out myself, but it appears to be another good solution.
For a toy project I want to find out if a mobile phone is connected to gsm or not. So I thought "Okay, let's use my local sip provider and see".
But in both cases, the thing goes like this:
I send an INVITE
0 s: I get a 100 Trying
5 s: I get a 183 Session description
I get an audio stream, in the one case with the ringing, in the other case with a "The person you are calling is…"
If I wait long enough (~ 40 s), I get a more appropiate status code like 180 Ringing.
Audio analysis is not an option, really.
Any hints on where to go now?
(I used twinkle for testing and a local german sip-provider.)
This issue is endemic in the way telephone networks work, and is not specific to SIP or IP. It's why, when you place a call to another country and the number is busy, you might sometimes hear your local country's busy tone, or you might hear a different busy tone that comes from the other country. In the latter case you cannot detect except by audio analysis, what the problem is. In SS7 and ISDN we speak of Q.931 cause codes instead of SIP error codes, but the principle is the same.
There's an argument to be made for configuring telephone systems to emit status codes instead of audio error messages. For callers using normal phones, the originating switch (the one closest to the caller) can then map that code to the appropriate spoken error message or audio tone. That way, when the call is being placed by software rather than by a person, the software can have access to the actual error code right away.
On the other hand you can also argue for having the remote switch (the one nearest the destination or the one that encounters the problem) speak its own error message. That switch knows best what the actual problem is. For example, a mobile operator can emit a spoken error message saying that the mobile phone you are trying to call is currently out of range. There is no Q.931 code (or SIP error code for that matter) with that meaning. It could return 27=Destination out of order?? Or 35=Destination unattainable?? Both of those codes are so esoteric, who knows what error message the local switch would translate them to (in practice: probably just a reorder tone, which is really user-unfriendly to a human caller). And when you try to map Q.931 cause codes to SIP error codes back and forth, even more information is lost because the codes really don't match up well at all. It's likely to be a much better user experience for the caller if the remote switch just plays back an informative, appropriate, recording which describes the problem.
Since there is this dilemma (arguments on both sides), we can conclude that this will not likely be resolved by completely standardizing on one way or ther other way anytime soon.
Anyway, sometimes this is configurable: your SIP provider may be able to configure your trunk for coded errors instead of recorded messages. If they offer this (some do), it's worth a try to set this option. But results will vary: this option only affects its local behaviour. In general if you want immediately call clearing with cause code and are instead getting a recorded error message from the other end, you will not be able to do anything about it, because the switch that makes the decision on which way it's going to respond is the remote one.
When using the audio message method, a proper Q.931 cause code or SIP error code usually comes eventually (after the recording is finished), but as you point out, it's probably too late by then.