I want to display info. on pole but no idea at all how to do it.
Please guide.
Thanks
Many such devices devices use RS232 or RS422 serial communication. Start with the hardware manual for the display to determine how to communicate with it. It will likely detail a specific protocol your application must use to set the message.
Related
I was tasked with devising a solution to initiate a voice call using a GSM Modem programmatically. The call will be initiated via an API and play and audio file or just ring a number and then drop the call. This is to be used to notify staff during the night about critical alarms on the network.
Does anyone know of a solution or worked on something similar?
GSM network modem with SIM Card is to be used.
I'm not sure the staff will appreciate an autodialer like feature, rather than a text or other message, but as this is your requirement I am guessing your customer must have already made the decision.
One good approach for which there is plenty of documentation is to use an Asterisk based solution.
If you are not familiar with it, Asterisk is a open source PBX which is capable of connecting, initiating and receiving calls.
There are several firms that made GSM/UMTS interfaces cards that you can host in a standard server/PC and use as you have described above (you want to make regular GSM voice calls not VoIP over data over a GSM model I am assuming).
Some specific info on your use case is here for example:
http://www.voip-info.org/wiki/view/Asterisk+auto-dial+out+deliver+message
I have a Netduino Plus with at transeiver attached via SPI. I would like to reset the transiever every time the Netduino restarts. Is it possible to programmatically power on/off the 3V3 pin?
I would recommend using a FET (controlled by one of the I/O) pins to enable/disable 3V3 power to your transceiver. When you say transceiver, I think "more than a few mA" :)
BTW, we took this feedback into account with the new Shield Base module for Netduino Go. It has an integrated FET on both 3V3 and 5V power headers, so you could enable/disable power to your shield in code. Once the new Ethernet go!bus module ships and the Shield Base comes out of beta (soon), your solution can be redeployed to Netduino Go + Shield Base with few/no code changes.
Chris
Secret Labs LLC
Looking at the circuit diagram ( http://www.netduino.com/netduinoplus/schematic.pdf ), I can see only the Micro SD Card Slot having its power controlled programmatically. You could rig up a relay to control it (via a transistor, of course) instead, or if the transceiver uses less than 130mA (the current limit of the device shown: http://www.datasheetarchive.com/BSS84W-7-F-datasheet.html) you could copy the circuit from the Netduino Plus. Buying a relay shield looks like overkill, but you might have other uses for it.
Have you looked into resetting the transceiver programmatically instead of the brute-force method of power-cycling it?
Just to provide another view. You could use a transistor powered off the netduino RESET line, this will reset the device every time the netduino reboots. Or you can just link the transistor to a spare digital pin and power it in code..
What specific SPI device are you using? You mention that it's a transceiver but we could probably provide better information if we know the exact part number. If your device requires less than 8mA the Netduino Plus specs seem to indicate that one option could be using a digital output pin as the power source.
Unfortunately Secret Labs don't use exactly the language I'd expect and call out the sink and source current maximums so I would contact them directly first to see if you risk blowing your chip. I'll see if I can get an answer from them and amend this post if/when I do.
Update: Sink and source current is the same on the Netduino. See my post on their forums about sink vs. source current for a more in depth explanation. So, if your device can run off of just a few milliamps you should be able to use a digital I/O pin to power it.
Also, a lot of devices have enable pins. You can usually reset them with that line instead of pulling the power if that helps. Sometimes with flaky hardware it is better to pull the power though.
We are running a course in robotics and Xbee is the most favorite communication protocol for the student. In last two years we helped them build around 62 various projects (40 more in pipeline).
All most all the projects involve sending different kind of data to the bot. Sometimes it is a 1 byte command where as sometimes it is a long string to be interpreted. Sometimes we face the issue of addressing a bot when one xbee is used in broadcast mode to send messages to a particular bot among several. Students use their creativity to address this issue each time.
I personally feel this is reinvesting the wheel. I wonder if any higher level protocol proposals exist for serial port communication and if there isn't any specific protocol design I wonder if if the worth designing one for the student needs.
Do you mean internal only protocol of your system? If yes, often embedded software engineers incline to roll their own protocols. Most of them talks that it lets them make most optimal system.
It is not ideal approach. I agree with you that it's good for students to learn good examples.
Unfortunately I don't know any protocol stack fitting well robotics application. But I advice you to try google's protocol buffer system, its able to simplify most efforts of building protocols engines, and it works with plain c too.
You can implement Modbus ASCII if you want to go with a standard protocol that's already open.
Comli is a master/slave protocol that is used in some older devices or when it is not possible to use ethernet. You can probably get the specification from ABB if you ask - it's no secret.
That said you can put an OPC server/client architecture on top of that to get a bit more powerful communication e.g.
+--------------+ +--------------+ +--------+
| OPC UA Client| -- | OPC UA Server| -comli- | Device |
+--------------+ +--------------+ +--------+
This would make your OPC UA client protocol indepedent which makes things a bit easier down the road.
Modbus is another serial protocol that is used a lot
I believe OPC will give you the highlevel operation that you want.
see
www.opcfoundation.org
www.abb.com
PS. OPC UA is not the same as the old OLE version and thus has nothing to do with COM/DCOM
Like mjh2007 said, Modbus is standard, open and easy. The only problem I can see is if you want the robot to respond "quickly" to a command, since serial Modbus uses timeouts to detect the end of a packet. You can get around this by ignoring the timeout requirements and calculating the expected size of a packet based on it's function code and parameters as you are receiving it, then you can start processing the command immediately upon receiving the last byte and verifying any checksums. This page has some more details on implementing such a scheme.
Be sure to make use of the XBee module's "Transmit Explicit" frame (type 0x11) running in API mode with ATAO set to 1. You can unicast to a particular bot on your network, instead of always broadcasting frames. On a mesh ZigBee network, you want to avoid broadcasts as much as possible.
I'm guessing you're either using "AT mode" for sending raw data, or using "API mode" with ATAO set to 0 (sometimes referred to as "transparent serial").
If you look at that frame type (0x11), you'll see that the recipient gets an 0x91 frame that contains multiple fields already (source/destination endpoint, cluster, profile ID). You can re-purpose those fields since you're not trying to do ZigBee networking.
We have developed an application on Windows.net mobile framework and it is used on a Windows 6.5 Smartphone. for our location based application. Our application is real time and tracks our employees. We are finding that the device loses its GPS signal.
Has anyone managed to restart the GPS receiver so that it starts giving the GPS signal again. I would be ever so gratefull if someone can help. We are using GeoFramework2.0 to deliver the geographic information that you need.
Regards
Sandy
The GPS is "shut down" when no application is using it. Just close your handles and re-open them.
If the GPS on your device is part of the WWAN radio (i.e. cellular phone) it may get put in to a low power state rather than being actually shut off. In that case, you can try restarting the radio.
If that doesn't work, some GPS's will allow you to send proprietary commands to them to force a reset or clear the memory. These commands are not standard and will differ significantly by manufacturer. If you have a SiRF GPS, take a look at the SiRF Binary Protocol Reference.
im trying to read the current position of GPS Device...using N95 from Nokia.
I read tht i will need my device to return the NMEA lines to the serialport and then i will parse/split it to get things I want but all along I dont know what to write to the serialport to make device return the NMEA ?
Like There are other commands of AT for messaging etc...Is there any specific command to send to serialport to get NMEA ???
I found this site site which seems to guide you through everything you need to do.
I am not sure how it works in the N95, but in my HTC phone you cannot send commands to the GPS device to have it behave in a certain manner. Once I am connected to the serial port that the GPS device uses I can read a stream of data coming from it, which happens to be NMEA data. There is no way that I have found to send commands to the device to tell it how to behave.
I haven't used that specific GPS device before, but for mine, I just have to open the port and I start receiving the NMEA data immediately.
I have an N82, and as far as I know it doesn't speak NMEA directly. I use a script from this page - specifically one the titled "# Turn your S60 phone with an internal GPS (eg your N95) into a Bluetooth GPS" - to get NMEA strings.
Ahh oki so I need to run some script.Oki I think i should buy a specific GPS Device for it.
Which device will do my job in cheapest manner ?
I've never worked specifically with the N95, but most GPS devices will just start spitting out NMEA as soon as they're powered up, regardless of whether or not they have a lock. I don't know how the N95 is designed, but I'll bet it probably wasn't designed to give you access to the raw NMEA data from the GPS. You'll probably need some pretty fancy trickery to get it to do that.
If you don't need to use the N95, you might find it easier to just get a GPS module and use that instead. I've always purchased mine from SparkFun. They have some good evaluation boards boards and tutorials to help you get started.
A great way of doing this in Java ME is to use JSR 179: the Location API. Your app needs to create an implementation of LocationListener, then set it on the default LocationProvider. When your listener's locationUpdated method gets called, call:
location.getExtraInfo("application/X-jsr179-location-nmea");
This will provide access to the NMEA sentences.
You can send this over a serial port by using the Java ME commports mechanism (use:
System.getProperty("microedition.commports");
as described here).
Hope this helps,
funkybro