I am on Ubuntu Mate and I am trying to set the baud rate for tty7. stty gives "unable to perform all requested operations". Any help?
It is not possible to set baud rate of the virtual terminal in this way. Since the /dev/ttyNUMBER devices are not real serial ports, it is not possible.
See this answer for details.
Related
Testpmd is running in a Hyper-V VM, and there are two NICs which connect to "internal virtual switch". I just want to test the availability of netvsc PMD.
./app/dpdk-testpmd -l 2,3 -- --total-num-mbufs=2048 -i --portmask=0x3 --port-topology=loop
I have used "start" or "start tx_first", and then used "show port stats all" to check. There are no Tx-packets or Rx-packets on two NICs.
Then I used "set fwd txonly", and I could find Tx-packets on two NICs, but it is not my want. So what steps can I do?
Typically, one wants to use a packet generator on the side that is opposite to a pair of ports harnessed by testpmd. Such a generator starts sending packets, whilst testpmd simply receives them on one port and transmits them back from the other one. This is what port-topology of type paired stands for, and this port-topology is used by default in testpmd. Another parameter, forward-mode, in turn, is set to io by default, which means that testpmd does not change the received packets before transmitting them back (in example, does not swap MAC addresses, etc.).
However, in your case there's no packet generator employed, and that means that testpmd must generate and send a batch of packets itself in order to kick-start forwarding. This is accomplished by specifying option --tx-first.
But apart from omitting option --tx-first you for some reason use option --port-topology=loop, which might be the reason behind your setup being non-functional. Variant loop means that packets received by a given port (say, Port 0) must be transmitted back from the very same port (that is, from Port 0). What you might want here is --port-topology=paired, which, as I stated before, is anyway used by default.
So, the short of it, you should probably try running testpmd as follows:
./app/dpdk-testpmd -l 2,3 -- --total-num-mbufs=2048 -i --portmask=0x3 --tx-first
Please note that this way forwarding is started automatically but you get no testpmd> prompt to enter command in. Should you wish to start forwarding automatically and, at the same time, get an interactive command prompt, please try running testpmd this way:
./app/dpdk-testpmd -l 2,3 -- --total-num-mbufs=2048 -i --portmask=0x3 --tx-first --auto-start -i
DPDK application testpmd is not a packet generator that will automatically generate and send Packets. But there is an option --tx-first which allows sending a burst (default 32) dummy packets from each interface.
Since your environment is physically connected this should work. But I highly recommend first check with the Linux driver whether ping or arp is able to reach the cross-connected interface first.
Note:
I highly recommend reading testpmd doc for more details
for enabling promiscus mode use option set promisc all on
Can anyone please explain how to establish a communication between stm32 dev board and gps module? I am not knowing how to send AT commands to gps module through MC through a source file through UART. Please clarify me in this aspect.
There is a lot of literature on STM32 and UARTs on the web. If I were you I would download the STM32CubeMX. This program generates most of the code for you. You select your processor (or development board), select the clocks and peripherals, and click Generate Code. It also comes with very handy example projects, and might even have a complete project with a working UART that you can put straight onto your board.
And I would first make sure my UART is fully working before connecting the GPS. This you can do by trying to echo. Connect your TX and RX pins with a wire. Then, everything you transmit you will receive as well. It's a easy test to see if everything is working.
I would also work through the TrueStudio IDE. It basically works plug and play
If you use the ublox module, you must use a serial port to communicate.
You have to connect RXD(ublox) to TXD(micro) and TXD(Ublox) to RXD(micro) ,
and config your StmCubemx like This :
http://wiki.sunfounder.cc/index.php?title=Ublox_NEO-6M_GPS_Module
Config Stm32 :
[Step 1: https://i.stack.imgur.com/1B4Ed.jpg ]
[Step 2: https://i.stack.imgur.com/6ULOm.jpg]
[Step 3: https://i.stack.imgur.com/GD0VL.jpg]
If you have another question, please ask
First of all, I think you should test AT command with module sim through (USB to UART) to PC in order to understand procedure operation, such as: module sim - TCP/IP - thingspeak server. The next time, you can refer this link for code: https://bitbucket.org/mbari_peter/sim800-mqtt-ravi/src/78e36076c89b4618cf57a538f0c70f91b2b876dd/modemDrivers.ino?at=master&fileviewer=file-view-default
If you have any questions or encounter any problems, you can ask! Thanks for reading!
Typically, GPS sends data # 1 Hz after starting up. You just need to capture this NMEA sentences and filter the receive buffer according to your requirement.
Try using UART receive interrupt. Make sure the baud rate of both GPS module and STM32 are same.
In my current scenario, I'm using NETLIGHT Pin (Pin no. 64) of SIM800 module with my PIC microcontroller to know whether my module is registered or not?
This way I built the circuit. Just I removed LED from VBAT. Then I connect collected of NPN transistor to pic micro input PIN.
I want to know whether any easy way using AT commands to find network registration status of SIM800?
Unfortunalty it's seem not to be really possible (or in fact detecting this state in only one way)
I use SIM800 and let it run for hours and I have seen many cases of network loose, while the AT+CREG? continue telling everything is OK.
Also, even with network down, the SIM800 continue sending you the name of the operator and the strengh of the signal.
The only way I've found is to monitor the serial port: when the SIM800 loose the network, it sends two messages:
+PDP: DEACT and
+SAPBR 1: DEACT
I suggest you to have a look at the document "SIM800 Series_AT Command Manual" and especially the chapter "19.3 Summary of Unsolicited Result Codes". You'll find +PDP and other interesting code (like under-voltage warning, DNS failed...) and see some of these messages are not linked to AT command.
From the manufacturer's documentation:
I have a GPS circuit board from china. The only information I can find on this thing is :"amoj GPS 04C www.amoj.com"
It has a serial (DB9) connection and I would like to determine how to putty into it or something.
How can I determine what the port settings that are required to access this?
Pictures below:
Photos in Dropbox
The Jupiter TU60 serial interface is 9600 8N1 by default. The only sentence it will output automatically is the flash checksum message about a second after power up. Google the datasheet for the device and it will let you know about this.
To have it output the position and other information, you must command it to do so. There is a default set of commands that are active after power up. They begin with ## and are from the protocol used by Motorola. Refer to the M12+ Users Guide and Supplement (available online) for information on how to use these commands. I have been able to enter them from Realterm. The only tricky part is calculating the checksum. You can use most hex calculators to do that.
According to the datasheet, the unit goes into survey mode automatically and after about 24 hours goes into position hold. The 1PPS and 10KHz signals are valid to less than a microsecond after a few minutes after power up and to 50nS after a day. I have compared this to another standard I have to verify this. You can use the ##Ea command to get the status of the unit and the M12+ Manual will tell you how to decode it.
Look for $GP... messages at 4800 and 9600BPS as yegorich suggest. Common NMEA messages output by GPS devices are $GPGGA, $GPVTG, $GPRMC.. If you find that data coming out, use Google to look up NMEA 0183 sentence structure and you will have what you need...
I have the same board with the Navman jupiter T Tu60 GPS 1pps 10khz GPS Module on it. I just received my sma antenna and have hooked it up. I am using 12.6V power to the centre pin.
It outputs 1pps on the led with no signal, so that is not to be trusted. Mine is labeled 1pps and 10khz underneath the pcb but these are actually swapped! I put the 10KHz output on my dso and get a 10KHz square wave 50% duty cycle signal but there is ringing on the waveform rise so I have to set the trigger level to 0.8v to get the dso to register the 10KHz frequency. I suspect this may be because the output expects a load and is not seeing one. Now, was I using ac or dc coupling?
I too am getting nothing on the serial. I tried 9600, 4800 using putty on com1 (I have a nice old motherboard) and then tried reversing rx and tx but no luck. As of now I am checking out the serial signals with the dso to see if I can work out what is happenning. I suspect that these boards are rubbish, and useful as power supplies only.
It reads 10.0000 on my hp 5328a counter and sometimes reads 9.9999. It would be nice to be able to talk to the gps to see whether it has satellite lock.
Please let me know how you get on and if you find out any further info.
Brett VK6EZ.
So, to open up a serial port and successfully transmit data from the balance through the serial port, i need to make sure that the settings on the serialPort object match the actual settings of the balance.
Now, the question is how do i detect that the connection hasn't been established due to the settings being different? No exception is thrown by serialPort.Open to indicate that the connection has been established. Yes, the settings are valid, but if they don't match the device (balance) settings; I am in the dark as to why the weight off the balance is not being captured.
Any input here?
Without knowing any more information on the format of the data you expect from your balance, only general serial port settings mismatch detection techniques are applicable.
If the UART settings are significantly incorrect, you'll likely see a lot of framing errors: when the UART is expecting a 1 stop bit, it will in fact see a 0. You can detect this with the ErrorReceived event on the port.
private void OnErrorReceived(object sender, SerialErrorReceivedEventArgs e)
{
if ((e.EventType & SerialError.Frame) == SerialError.Frame)
{
// your settings don't match, try something else
}
}
If things are close, but still incorrect, the .NET serial port object may not even give you an error (that is, until something catastrophic occurs).
My most common serial port communication failure occurs due to mismatched baud rates. If you have a message that you know you can get an 'echo' for, try that as part of a handshaking effort. Perhaps the device you're connecting to has a 'status' message. No harm will come from requesting it, and you will find out if communication is flowing correctly.
For software handshaking (xon xoff) There's very little you can do to detect whether or not it's configured right. The serial port object can do anything from ignore it completely to have thread exception errors, depending on the underlying serial port driver implementation. I've had serial port drivers that completely ignore xon/xoff, and pass the characters straight into the program - yikes!
For hardware handshaking, the basic echo strategy for baud rate may work, depending on how your device works. If you know that it will do hardware handshaking, you may be able to detect it and turn it on. If the device requires hardware handshaking and it's not on, you may get nothing, and vice versa.
Another setting that's more rarely used is the DTR pin - data terminal ready. Some serial devices require that this be asserted (ie, set to true) to indicate that it's time to start sending data. It's set to false by default; give toggling it a whirl.
Note that the serial port object is ... finicky. While not necessarily required, I would consider closing the port before you make any changes.
Edit:
Thanks to your comments, it looks like this is your device. It says the default settings should be:
1200 baud
Odd parity
1 stop bit
Hardware handshaking
It doesn't specify how many data bits, but the device says it supports 7 and 8. I'd try both of those. It also says it supports 600, 1200, 2400, 4800, 9600, and 19200 baud.
If you've turned on hardware handshaking, enabled DTR (different things) and cycled through all the different baud rates, there's a good chance that it's not your settings. It could be that the serial cable that's being used may be wired incorrectly for your device. Some serial cables are 'passthrough' cables, where the 1-9 pins on one side match exactly with the 1-9 pins on the other. Then, you have 'crossover' cables, where the "TX" and "RX" cables are switched (so that when one side transmits, the other side receives, a very handy cable.)
Consider looking at the command table in the back of the manual there; there's a "print software version" command you could issue to get some type of echo back.
Serial ports use a very, very old communications technology that use a very, very old protocol called RS-232. This is pretty much as simple as it gets... the two end points have synchronized clocks and they test the line voltage every clock cycle to see if it is high or low (with high meaning 0 and low meaing 1, which is the opposite of most conventions... again an artifact of the protocol's age). The clock synchronization is accomplished through the use of stop bits, which are really just rest time in between bytes. There are also a few other things thrown into the more advanced uses of the protocol such as parity bits, XON/XOFF, etc, but those all ride on top of this very basic communication layer. Detecting a mismatch of the clocks on each end of the serial line is going to be nearly impossible -- you'll just get incorrect data on the recieving end. The protocol itself has no way built in to identify this situation. I am unaware of any serial driver that is smart enough to notice the input data being clocked an an inappropriate frequency. If you're using one of the error detection schemes such as parity bits, probabilistically every byte will be declared an error. In short, the best you can do is check the incoming data for errors (parity errors should be detected by your driver/software layer, whereas errors in the data received by your app from that layer will need to be checked by your program -- the latter can be assisted by the use of checksums).