What's output data of a GPS receiver? I have some information about NMEA but I want to know If all GPS receivers have same output or not?
thank you
More or less they have the same output.
They differ only at very special topics, like raw data output option for special evaluations.
The GPS chip manufctures specify which NMEA sentences they support.
You might want to read e.g the ublox protocoll specification downlodable from the ublox homepage.
The following NMEA sentences are widley used with GNSS modules;
GGA, GGL, GSA, GSV, RMC, VTG, ZDA
Note that the RMC sentence is the recommended minimum for navigation devices.
This highly depends on the receiver model used and what kind of data you are looking for. Basically, two different types of outputs can be available, position solutions (including velocities) or raw measurements (the observables for each satellite). Some receivers (the cheaper ones) are limited to position output, while other receivers can output the raw data as well. For positions, the NMEA format is quite handy, but not for raw measurements. These are usually output in a binary, proprietary protocol which is different between the various receiver manufacturers. However, most receivers include some tools which allow the transformation of these propietary protocols into the RINEX format. This is the "receiver independent exchange format", but is used for post-processing rather than for live output.
Additionally, professional GNSS receivers can be configured quite flexibly, so that the type of output, the update rate and the output port (network, serial ports, bluetooth, usb, ...) can be configured as desired.
A very handy toolkit to work with different types of GNSS receiver is the RTKLIB (http://www.rtklib.com/), an open-source program package for various tasks related to satellite navigation systems.
Related
I'm completely new to the space and i have a project that i would like to complete, the project is basically: extracting sensor data in the form of MODBUS than sending the data out through CANBUS. i already have a mod-bus input and a can-bus output.
researching into MODBUS has been a bit confusing so sorry if these questions seem a bit stupid.
Is it possible to write code which can convert MODBUS to CANBUS? or will i need external hardware.
additionally, i'm looking to add a microprocessor to my dev board, is there anything in specific i should look for that would help with my modbus and canbus operations? or will any microprocessor work.
thank you
The basics of all data communication is the OSI model. Start there. Then you'll eventually find out that Modbus is an application layer protocol standard and CAN is a physical/data-link layer standard.
Therefore your question doesn't make any sense. You can't convert an application layer into a physical/data-link layer. You can however convert Modbus to some specific application tier protocol for CAN, such as for example CANopen, Device Net or J1939. Or a custom one.
The lowest layers underneath Modbus is UART and most likely RS-485. Possibly RS-232.
You will need a RS-485 or RS-232 transceiver between the Modbus sensor and your MCU. And you will need a CAN transceiver between your MCU and the CAN bus. Additionally, it is very strongly advised to pick a MCU with built-in CAN controller hardware.
Pick a target hardware that suits your project, don't pick some random dev board and then try to duct tape it with misc hardware to suit the project requirements.
However, the hardware is the easy part. Buying and configuring protocol stacks for whatever application protocols you are using is the hard and expensive part.
Also, there are lots of companies making gateways, so why re-invent the wheel. If you need to convert between for example Modbus and CANopen, these are both well-known industry standards. Consider just buying a gateway.
I'm trying to directly communicate with the GNSS chip on my device and I am not clear whether the RAW GNSS information is coming directly from the GNSS chip or not. I have used the application provided in the link and it seems to read longitude/latitude information.
Is this information directly coming from the GNSS chip? Further, is the GNSS driver enough to extract this information? Or is longitude/latitude info calculated based on GNSS raw data? If it's the latter, how do I calculate longitude/latitude from raw GNSS (a reference would be sufficient)?
Note: I am not interested in very high accuracy location nor am I interested in indoors location retrieval (using Wi-Fi and Carrier services). I want to record the GPS (or Glonass or whatever) and save it as longitude/latitude format.
Apparently, GPS gives the information. I have found a partial answer here. (this is for GPS, it does not include other GNSS chips like Glonass and Galileo).
Apparently, the GPS hardware outputs results following NMEA format. From the page:
GPS is a commonly used constellation of GNSS satellites. GPS hardware typically reports location information as ASCII strings in the NMEA standard format. Each line of data is a comma-separated list of data values known as a sentence. While each GPS module may choose to report different portions of the NMEA protocol, most devices send one or more of the following sentences:
GPGGA (Fix Information): Includes position fix, altitude, timestamp, and satellite metadata.
GPGLL (Geographic Latitude/Longitude): Includes position fix and timestamp.
GPRMC (Recommended Minimum Navigation): Includes position fix, speed, timestamp, and navigation metadata.
Therefore, GPS driver is sufficient to give longitude/latitude information.
The N210 is connected to the RF frontend, which gets configured using the GNU Radio Companion.
I can see the signal with the FFT plot; I need the received signal (usrp2 output) as digital numbers.The usrp_sense_spectrum.py output the power and noise_floor as digital numbers as well.
I would appreciate any help from your side.
Answer from the USRP/GNU Radio mailing lists:
Dear Abs,
you've asked this question on discuss-gnuradio and already got two
answers. In case you've missed those, and to avoid that people tell
you what you already know:
Sylvain wrote that, due to a large number of factors contributing to
what you see as digital amplitude, you will need to calibrate
yourself, using exactly the system you want to use to measure power:
You mean you want the signal power as a dBm value ?
Just won't happen ... Too many things in the chain, you'd have to
calibrate it for a specific freq / board / gain / temp / phase of the
moon / ...
And I explained that if you have a mathematical representation of how
your estimator works, you might be able to write a custom estimator
block for both of your values of interest:
>
I assume you already have definite formulas that define the estimator for these two numbers.
Unless you can directly "click together" that estimator in GRC, you will most likely have to implement it.
In many cases, doing this in Python is rather easy (especially if you come from a python or matlab background),
so I'd recommend reading at least the first 3 chapters of
https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
If these answers didn't help you out, I think it would be wise to
explain what these answers are lacking, instead of just re-posting the
same question.
Best regards, Marcus
I suggest that you write a python application and stream raw UDP bytes from the USRP block. Simply add a UDP Sink block and connect it to the output of the UDH: USRP Source block. Select an appropriate port and stream to 127.0.0.1 (localhost)
Now in your python application open a listening UDP socket on the same port and receive the data. Each sample from the UDH: USRP Source is a complex pair of single prevision floats. This means 8 bytes per sample. The I float is first, followed by the Q float.
Note that the you need to pay special attention to the Payload Size field in the UDP Sink. Since you are streaming localhost, you can use a very large value here. I suggest you use something like 1024*8 here. This means that each packet will contain 1024 IQ Pairs.
I suggest you first connect a Signal Source and just pipe a sin() wave over the UDP socket into your Python or C application. This will allow you to verify that you are getting the float bytes correct. Make sure to check for glitches due to overflowing buffers. (this will be your biggest problem).
Please comment or update your post if you have further questions.
I want to interface two microcontrollers with a UART interface and I search a protocol to exchange data between them.
In practice, I want to exchange data periodically (ie: sensors reading) and also data on event (GPIO state). I have around 100-200 bytes to exchange every 100 milli second.
Does anybody know a protocol or library to achieve this kind of task ?
For now, I see protobuf and nano protobuff ? Is there something else ?
It would be nice if I could add a software layer over the UART and use "virtual data stream" like if it was a TCP/IP connection to N ports.
Any idea ?
Thanks
I think the most straight forward way is to roll your own.
You'll find RS232 drivers in the manufacturers chip support library.
RS232 is a stream oriented transport, that means you will need to encode your messages into some frameing structure when you send them and detect frame boundaries on the receiver side. A clever and easy to use mechanism to do this is "Consistent Overhead Byte Stuffing".
https://en.wikipedia.org/wiki/Consistent_Overhead_Byte_Stuffing
This simple algorithm turns zeros in your messages into some other value, so the zero-byte can be used to detect start and end of frame. If a byte gets corrupted on the way you can even resynchronize to the stream and keep going.
The code on Wikipedia should be easy enough even for the smallest micro-processors.
Afterwards you can define your message format. You can probably keep it very simple and directly send your data-structures as is.
Suggestion for a simple message format:
Byte-ID Meaning
---------------------------------
0 Destination port number
1 message type (define your own)
2 to n message data
If you want to send variable length messages you can either send out a length byte or derive the length from the output of the Constant Overhead Byte Stuffing framing.
By the way, UART/RS232 is nice and easy to work with, but you may also want to take a look at SPI. The SPI interface is more suitable to exchange data between two micro-controllers. It is usually faster than RS232 and more robust because it has a dedicated clock-line.
How about this: eRPC https://community.nxp.com/docs/DOC-334083
The eRPC (Embedded Remote Procedure Call) is a Remote Procedure Call (RPC) system created by NXP. An RPC is a mechanism used to invoke a software routine on a remote system using a simple local function call. The remote system may be any CPU connected by an arbitrary communications channel: a server across a network, another CPU core in a multicore system, and so on. To the client, it is just like calling a function in a library built into the application. The only difference is any latency or unreliability introduced by the communications channel.
I have use it in a two processor embedded system, a cortext-A9 CPU with a Context-M4 MCU, which communicate each other with SPI/GPIO.
Erpc can run over UART, SPI, rpmsg and network(tcp). even when using serial or SPI as transport tunnel, it can do bidirectional
calls and with very minimal footprint.
Simple serial point-to-point communication protocol
http://www.zipplet.co.uk/index.php/content/openformats_mise
It depends if you need master/slave implementation, noise protection, point-point or multi-point (and in this case collision detection), etc
but, as our colleague said, I would go with the simplest solution that fits the problem, following the KISS principle http://en.wikipedia.org/wiki/KISS_principle
Just add some header information like ID and length, if necessary CRC checking, and be happy :)
Try Microcontroller Interconnect Network (MIN) 1.0:
https://github.com/min-protocol/min
It has framing using byte-stuffing to keep receiver sync, 16-bit Fletcher's algorithm for checksum, an identifier for use by the application and a variable payload of up to 15 bytes.
There's embedded C code there plus also a Python implementation to make it easier to talk to a PC.
As the first answer starts, the simplest result is to roll your own. Define your header (the "format" above) as needed, perhaps including status information so each processor knows that the other is working properly. I have had success with a protocol that includes
2 byte ascii prefix and suffix such as "[" and "]" so that a
protocol analyzer can show you message boundaries.
The number of bytes.
The command ID (parsed to indicate what command handler to use.
Command arguments (I used 3 32 bit words).
A CRC or checksum to verify transfer integrity
The parser then recognizes the [* as the start of the message, and dispatches the body to the command handler for the particular command ID with the associated arguments as long as the checksum matches.
I have a ZyXEL USB Omni56K Duo modem and want to send and receive voice streams on it, but to reach adequate quality I probably need to implement some "ZyXEL ADPCM" encoding because plain PCM provides too small sampling rate to transmit even medium quality voice, and it doesn't work through USB either (probably because even this bitrate is too high for USB-Serial converter in it).
This mysterious codec figures in all Microsoft WAV-related libraries as one of many codecs theoretically supported by it, but I found no implementations.
Can someone offer an implementation in any language or maybe some documentation? Writing a custom mu-law decoding algorithm won't be a problem for me.
Thanks.
I'm not sure how ZyXEL ADPCM varies from other flavors of ADPCM, but various ADPCM implementations can be found with some google searches.
However, the real reason for my post is why the choice of ADPCM. ADPCM is adaptive differential pulse-code modulation. This means that the data being passed is the difference in samples, not the current value (which is also why you see such great compression). In a clean environment with no bit loss (ie disk drive), this is fine. However, in a streaming environment, its generally assumed that bits may be periodically mangled. Any bit damage to the data and you'll be hearing static or other audio artifacts very quickly and usually, fairly badly.
ADPCM's reset mechanism isn't framed based, which means the audio problems can go on for an extended period of time depending on the encoder. The reset code is a usually a set of 0s (16 comes to mind, but its been years since I wrote my own ports).
ADPCM in the telephony environment usually converts a 12 bit PCM sample to a 4 bit ADPCM sample (not bad). As for audio quality...not bad for phone conversations and the spoken word, but most people, in a blind test, can easily detect the quality drop.
In your last sentence, you throw a curve ball into the question. You start mentioning muLaw. muLaw is a PCM implementation that takes a 12 bit sample and transforms it using a logarithmic scale to an 8 bit sample. This is the typical compression mechanism for TDM (phone) networkworks in North America (most of the rest of the world uses a similar algorithm called ALaw).
So, I'm confused what you are actually trying to find.
You also mentioned Microsft and WAV implementations. You probably know, but just in case, that WAV is just a wrapper around the audio data that provides format, sampling information, channel, size and other useful information. Without WAV, AU or other wrappers involved, muLaw and ADPCM are usually presented as raw data.
One other tip if you are implementing ADPCM. As I indicated, they use 4 bits to represent a 12 bit sample. They get away with this by both sides having a multiplier table. Your position in the table changes based on the 4 bit value (in other words, the value is both multiple against a step size and used to figure out the new step size). I've seen a variety of algorithms use slightly different tables (no idea why, but you typically see the sent and received signals slowly stray off the bias). One of the older, popular sound packages was different than what I typically saw from the telephony hardware vendors.
And, for more useless trivia, there are multiple flavors of ADPCM. The variances involve the table, source sample size and destination sample size, but I've never had a need to work with them. Just documented flavors that I've found when I did my internet search for specifications for the various audio formats used in telephony.
Piping your pcm through ffmpeg -f u16le -i - -f wav -acodec adpcm_ms - will likely work.
http://ffmpeg.org/