VI I am using
I am doing a project in which I am receiving data bby Xbee at remote end. I have set the baud rate of sending and receiving side,115200.
I need to send 3000 bytes every time. With the baud rate mentioned, the data must be received in less than a second. I have used LabVIEW for displaying the data waveforms.Now the problem is I am receiving data in 2 seconds in Xctu.but in LabVIEW if I receive the same data and plot it,the waveforms get disturbed. But if I increase the sending time, say 7 seconds,the waveforms are good.Now the problem is with LabVIEW speed to update the previously received data with new data so that I could plot the waveforms correctly.That's why I e want to give complete access of com port to LabVIEW.
Please help me.
I think this is because of the loop inside the loop. I will be able to read next package when the inner loop is stoped.
Everything else is correct and should not cause a problem.
PS. Make sure you set baud rate and correct VISA port before you run the LabVIEW code.
Go into the Labview search example section, then search "consumer" : you will open a vi named "Simple Queue.vi" and you'll have a producer/consummer functionnal program
Related
I'm using Lora 1276 and Arduino to collect data from here every nodes.
The example code I use is from here and it work successfully!
As far I know, LoraWAN is using TDMA to distribute the time to any nodes.
And polling by the gateway to get the data. That can make the nodes keep low power consume and let gateway to be control master.
I searched some information about preamble which is at the front of packet, nodes will decide whether to reply after received. If nodes receive a preamble that does not match,it will go back to sleep.
Is there any sample code for polling mode?
Thanks.
LoraWAN Class B devices do indeed use TDMA for scheduling periodic receive windows.
Here is sample code implementing Class B. https://github.com/Lora-net/LoRaMac-node/tree/master/src/apps/LoRaMac/classB
I have been trying to set up two XBees to communicate since the last three days. X-CTU seems to be the perfect option to do so, however, it is a real menace when it comes to discovering XBees on serial ports.
I was able to detect one XBee by luck just once and the other one never showed up. I have even replaced both my XBees. I am trying to figure out the alternative, i.e. using a serial console to perform the operation. I haven't been able to receive an OK response from the device upon issuing +++.
Since I haven't had a good experience using a PC to communicate with ESP8266 devices earlier, I tried to figure out a workaround by using the second Serial port of an Arduino to send such configuration messages and read the response by printing it out on the default serial console.
It also appears that configuration messages can differ depending on the mode of the device. If it's in API mode, the frame has to be generated in a specific format (I use the X-CTU frame generator for this purpose).
Why am I not able to receive a response from the XBee upon issuing a +++?
The devices are Series 1 XBees and the exact part number is XB24-AWI-001. Any help is highly appreciated.
Have you considered the XBee being in API mode? Maybe should you consider to reflash the device in AT mode to start playing with it.
To test if it's in API mode, you can refer to the guide, chapter 9 for the API mode structure:
http://eewiki.net/download/attachments/24313921/XBee_ZB_User_Guide.pdf?version=1&modificationDate=1380318639117&api=v2
Basically, a datagram in API mode starts with ~, and it's built as follows:
[0x7E|length(2B)|Command(1B)|Payload(length-1B)|Checksum(1B)]
As 0x7E is ~ on the ASCII table, you should try typing a bogus datagram in a serial terminal session like:
~ <C-d> AAAA
N.B.: The <C-d> characters means Control-d under unix., which is the EOF character.
Obviously such a message isn't likely to work, and you will receive a reply asking you to send that datagram again. That's because the EOF character being ASCII code 4, it means that the length of the datagram will be 4 bytes. So then you send four bogus bytes, the checksum will be A, which is very likely to be right, and the receiver will assume the transmission has been corrupted. So the datagram will be asked again, meaning you will receive a datagram to do that query.
Though I can only advice you to consider running it only in API mode (more reliable and a better API, but you cannot play around with it and understand what's going on by tapping on the line with a logic analyzer… though giving enough time, you'll start to read API datagrams like it's English ☺).
I wrote a page with a few resources to check on how to reflash the XBees:
https://github.com/hackable-devices/polluxnzcity/wiki/Flash-zigbee
and here's other advices from another totally unrelated project:
https://github.com/andrewrapp/xbee-api#documentation
And I also wrote a lib (aimed at beaglebones but you can tweak it for your use) that handles API mode 2 with XBees:
https://github.com/hackable-devices/polluxnzcity/blob/master/PolluxGateway/include/xbee/xbee_communicator.h
https://github.com/guyzmo/polluxnzcity/blob/master/PolluxGateway/src/xbee/xbee_communicator.C
but I bet with a little google search you can find more widely used libraries than those ones, and even some aimed to be run on Arduinos (N.B.: that lib was originally written for Arduinos, and then adapted to run for Beaglebone, so reversing the operation shouldn't be hard).
I am using an Arduino Pro Mini 328P (3.3v, 8Mhz) with Xbee series 1. I have set the frequency to 1 Mhz and the baudrate to 9600. Also I have set baudrate to 9600 in the Xbee. I have also tested that at this baudrate Xbee is sending the data properly in a normal scenario.
Now what I have done in my project:
I have registered my Xbee with the gateway and then it will go to sleep (I have used pin hibernate mode) then it will wake up by a digital pin of the Pro Mini. I have put a delay of 19ms, after which the Xbee will try to send data. After sending the data it will go back to sleep.
The problem is that it behaves randomly when sending data to the gateway (which also has the same Xbee series1). Sometimes it sends the data perfectly, sometimes sending fails. I have also enabled RR to retry 6 times in case the Xbee fails to send the data the first time.
I have no idea how to solve this problem because of the randomness in sending the data.
I have put two Xbees nearer (I have two nodes with the same hardware and the same code). There is an interval between of around 4 minutes. So when one Xbee sends the data perfectly, after that 4 minutes gae (time difference of two RTC on different nodes) the other one fails to send the data. In this condition what can I conclude?
As a side note, the Xbee will try to send the data every hour. To calculate that hour I have to use an RTC, which seems to work fine (I am sure because I have taken the logs, the RTC never fails to generate an interrupt).
So I am wondering what could be the possible reason and how can I fix this problem (without restarting anything if it is possible then nothing will be better than that).
And I have no choice to restart my controller.
How to debug this?
A few things. If possible, increase your baud rate so you spend less time sending data to/from the XBee. If you have a limited power budget, faster baud rates save time and energy. I don't know how the UARTs work on the Arduino, so I can't say whether 115,200bps is possible with a 1MHz CPU clock.
Second, make sure you wait for the XBee to assert CTS back to the Arduino after you wake it up. Never send to the XBee unless it's "clear to send".
Third, if you use API mode, you can watch for a "Transmit Status" frame from the local XBee back to the Arduino which will let you know when the module has successfully sent the frame, and it's safe for you to put it back to sleep.
I am facing the following problem. I need to connect a sensor to a pc via serial port. i know exactly the values of baud rate (38400), 8 data bits, 1 stop bit and no parity. So i connect the sensor to the computer and i am not seeing any data transmitted to the pc. Note: the sensor is read only. i mean that there is not any handshake.
Do you have any ideas about why i don't get any data?
the connections are ok because i am connecting another device and in the other device i am able to read data.
Thanks everybody in advance!
it could be HW problem. Can you test it on different computer? From where is the sensor getting power? Some parasitic powering on DRT,RTS lines?
The easiest way is using oscilloscope/digital analyzer to see what's going on the line. With sound card oscilloscope like https://www.zeitnitz.eu/scope_en you should be able to see at least some bursts albeit it's sampling frequency is to low to see the data.
I am trying to write a Labview program that takes input from a thermal sensor on serial port RS - 232, applies some basic transformation to it, and displays it on a screen.
I'm wondering if it is possible to somehow simulate the sensor in labview, or by using some external simulator application so I can test my program before I'm given access to the actual hardware.
Is this possible?
I have Labview 2011.
The quickest way to test your VI's logic would be to make a CSV file of example data, and temporarily replace the section that reads from the sensor with a section that reads data values from the CSV file at the same rate.
It's probably not worth trying to emulate the serial port input at a lower level as Labview is generally very reliable at getting data from hardware into your VI - it's up to you then what you do with it!
You could have another program simulate the sensor and write to a different COM port. Then you could connect these COM ports with a null modem cable.
In order to do so, you'll have to work out how your sensor works and feed data in na appropriate format into that 2nd COM port. These data will end up being received by the 1st COM port and eventually by your application-to-be-developed.
If you encapsulate all of your communications code in a subVI or set of subVI's, separate from the code that does the transformation and display part, you can easily substitute test code and test data for the real sensor data. You could write a subVI that generates the test data and replace it with the real sensor comms subVI later, or you could use a case structure in the subVI to choose between communicating with the real sensor and just outputting test data (which, as Moray suggests, you could read in from a file so that you can easily change it).
I would suggest that you write separate subVIs for opening communications to the sensor, getting a data point from it, and closing the comms port when you are finished (though you can probably just use the serial or VISA close function for that). Chain these VIs together using the comms port (aka VISA session) and error wires. The 'open' VI could take an input that specifies whether real/simulated data is to be used and store that choice in a global variable (or a functional global VI) which the 'get data' VI checks each time it is called.
glglgl's suggestion of sending the simulated data from another serial port is also good; all you need to do here is use the serial send and receive functions in some sort of loop to do the same thing as the real sensor would, in terms of receiving commands and sending an output back. This has the advantage that you don't need to make any changes to your main program which should work exactly the same whether it's connected to the real sensor or the simulation program. However, problems with serial comms in the real world often result from instruments or devices that don't do exactly what their specifications claim they do, so just because your program works perfectly with your simulation doesn't guarantee it'll work perfectly with the real sensor if the real sensor does something you didn't expect :-)
Though the other answers offered some really great ideas, I've found an easier way to simulate sensor input that would be convenient for beginners.
Create virtual serial ports on your computer by using a Virtual port simulator. http://www.eltima.com/products/vspdxp/
Get a Modbus simulator. http://www.plcsimulator.org/
Download Labview Modbus Library. http://zone.ni.com/devzone/cda/epd/p/id/4756
Open the Labview Modbus library and run 'MB Serial Master Example.vi'
Now it should be possible to read/write values into the simulator using the example program.
The Block Diagram of example program can be analyzed to find out how data is being transferred behind the scenes on Modbus protocol.