I recently bought an Arduino with an LCD screen. I want to push information from my computer to the Arduino. I came across a great article, How to make a physical Gmail notifier. From what I understand, I have to send the information using Serial and read it in the C/C++ code on the Arduino. That is fine, but I want to send different information to the device.
Say I want to have one part of the LCD-screen showing the temperature outside and another part of the screen display when the next bus is coming. Is there any way to "mark" the information I send with Serial, or does everything end up in the same "channel"?
If that is the case, is there a logical, simple way to separate this information so it does not mistake bus-information for temperature and vice versa?
You need a protocol for sending information across the serial line, so that the data can be collected the other end in a way that makes sense. A simple protocol may be:
T:16.0 09.34 // Temperature, 16.0°C measured at 09.34
B:11b 11.46 // Bus, route 11b, arrives at 11.46 at your bus-stop.
M:mats#example.com 11kb 10.23 // Mail from mats#example.com, it's 11KB and arrived at 10.23
Each line contains one type of information.
Assuming the line of communication is reliable (and as long as your wire isn't several dozen feet, it should be), you don't need more than that. If the communicatio is unreliable, you need some sort of "start" and "end" markers (or a start and a length), a checksum and some way of dealing with "it went wrong". You will also need to read with a timeout, so that when you don't get enough data, the system starts over again with the next bit of information.
Is there any way to "mark" the information I send with Serial
Definitely. YOU decide how the information is sent if you have control over the information passing over the serial port on your computer.
or does everything end up in the same "channel"?
Well, the serial port is a kind of a channel I guess, since all information you wish to send to the Arduino goes over the port.
is there a logical, simple way to separate this information so it does not mistake bus-information for temperature and vice versa.
Yes. Say you want to send temperature data. Create a byte array for example in this manner: {T23.4} = Temperature data
The bracket '{' signals to the receiving code in the arduino that information is coming down the line with some data. The letter T indicates temperature. Everything after the letter 'T' up to the '}' is data. (23.4)
Bus information could be {Bxxx} where xxx is the data.
Related
I will construct a fictional app in order to construct my question.
I write a kind of treasure hunt app where the user gets a prize if they visit several locations around town. In effect the app would get their current lat/lon and check its proximity to the list of "treasure locations", if they are within 10 meters of any treasure location they get a notification.
The app will then do a http post to a remote script which basically inserts into a database. The post parameters will be uuid of device and the location they visited.
An attacker could easily watch wireshark and get the name of the script along with the parameters. They could go further, decompile the apk and get other things such as any hashing/obfuscation. They could then just use curl to post willynilly as they pleased and the game would be ruined for non-cheaters. This is a problem have never had to really address since in all the apps I have written there is always data which isnt sensitive and I dont mind it being exposed to the public.
What do I do?
The best think you could do is to send the data in a secure manner. Using HTTPS would be a much better choice, regardless of method. This effectively prevents eavesdroppers, it is the fundamental technology behind any secure communication on the internet.
Aside from the protocol to communicate with the server, there are still insecurities. Essentially, there are three methods that could work to overcome these.
The location of the player could be sent to the server at some periodic interval. The server responds back if they are close enough to one of the areas. Perhaps the server could include enough smarts to know that it takes time to get from point A to point B.
A single location could be sent at a time to the app. The track of the user could also be uploaded, to verify that the location is correct.
The locations could be sent through a one way function to the program. The real answer could be then sent to the server. The problem with this is that the exact location would need to be discovered in order for the same hash to result back. However, as GPS coordinates tend to only be accurate to a few meters, and don't tend to give insignificant digits, then multiple values could be tested near the current location. The one-way function would have to require some time to calculate in an effective manner, as otherwise it would be trivial for a bad guy to simply test every square meter in the city to figure out what would work.
The best method from a security standpoint would be the first, as at no time does the application know where it is supposed to go, until it reaches that location. Of course, this pings the server a large number of times needlessly.
I am responsible of the network part of a multiplayergame.
I hope anybody of you got some eperience with that.
My questions are:
Should I create an Object which contains all information (Coordinates, Stats, Chat) or is it better to send an own Object for each of them?
And how can i avoid the Object/s beeing cached at the client so i can update the Object and send it again? (i tried ObjectInputStream.reset() but it still received the same)
(Sorry for my bad english ;))
For every time send all data is not good solution, just diff of previous values can be better. Sometimes(eg 1 time for every 10 or maybe 100 update) send all values to sync.
1.in the logic layer, you can split the objects, and in transmission layer you send what you want, of course you can combine them and send.
2.you can maintain a version for each user and the client also have the version number, when things change, update the corresponding version in the server and then send the updates to all the clients, then the client should update version. it should be a subcribe mode.
I want to write an app in java that lets two clients talk via webcam. The way it works is both clients connect to a webcam that takes pictures at a specified frame-rate (20 per second maybe) then reduced the size and resolution, then sends it to the other client via a UDP packet. My question is - should I send every picture in its own Datagram Packet? I've read that they can only hold half a kilobyte at most so should every pic be cut down that much? Or should I have it split up into several Packets?
Are you sure you want to transmit whole images, instead of using an algorithm / codec that transfers only what needs to be updated?
If you choose the second option you can take some ideas from this previous question and a already used and tested library for the purpose. I believe i'd go with VLC java bindings if i had to do it. You should evaluate what is the best codec for your specific purpose (bitrates, quality, etc).
If you nevertheless want to transmit images i'd suggest you break them down into udp datagrams, remember that they should be somehow numbered/tagged so that the client can reconstruct the image as packets come (they won't necessarily come in the same order you send them), also you need to think what the client needs to do when some of the packets fails to arrive (discard the image, request previous packet, etc.).
One last thought, the udp datagram max size might not be the best option as well, your server-client should perhaps implement a algorithm and negotiate the udp frame size depending on the speed of the transmission.
What you should be doing is encoding a video stream. Leave the network layer alone, let it do fragmenting for you.
Also, if you are sending video over UDP, you will likely want to throw in a keyframe every 2 seconds or so.
Do not send each frame as its own image. Use a video compressor.
I would like to design a PvP game uses flash in client and java socket server, but I do need server validates trajectory and if bullets hit target from cheating.
Is there any tutorial or paper provides how to do this ?
To do it you need to have a server-side logic.
Mainly you will use clients just to show gamestates that are sent by server (if you want you can also let your clients show whatever they think is right until a new gamestate is received and synch to it) and to send to the servers just actions that are done (clicks or key presses) while your server should take care of everything else..
clients should be mainly frontends for the world representation..
The general idea for a uncheatable multiplayer game is:
You should only send the keys the user is pressing, the server stores it and after some intervals, it processes the informations and send a snapshot of the current position of all objects in the game.
Maybe if you don't want to waste too much network traffic:
You could save everything's position for 2 seconds, record the last user input (with the input, he may also send his last snapshot id), then send only what differs from the position now and what the user have.
Since you asked for patterns, I am assuming you understand the kind of logic you want to write on server side, but not sure about how to organize your code.
You should look at strategy pattern (http://en.wikipedia.org/wiki/Strategy_pattern) once. Since in this problem based on various locations on the screen, you need to change the way server validates the data, strategy pattern is a good fit for the problem.
#Jack: +1, and you should not actually do physical exercises at server,server just check start point, end point, range and time ect... if they are reasonable!
I am trying to understand the CANopen protocol.
For now, I do not have any CAN hardware nor the CANopen stack to experiment with.
I would like to know how to write a Java program to simply interpret CANopen messages that are received at the RS-232 port.
Are there CAN interfaces that are installed as a serial port?
Will I be able to write a program to process CANopen messages? I want only to be able to receive and interpret messages. Is it as simple as creating a buffer for the input stream and then break up the transmission into separate messages according to the SOF and EOF? How do I know what is the SOF/EOF since it is only 1-bit long?
Why is there a limit on the number of PDOs of a CAN node?
How do I process the PDO to identify the node from which it is sent and the data type and value? Is the PDO a standard CAN frame?
I don't know of any CAN interface that connects to the serial port (it wouldn't be too hard to create one based on a microcontroller with CAN and serial ports). However, standard serial ports would be too slow to support the higher speeds available in CAN.
Generally, when using the API for a CAN interface, you will be able to read messages consisting of ID, Length and up to eight bytes of data. You don't need to care about SOF/EOF. Even if interfacing directly on the low level with a CAN controller (that is, if you have a CAN interface for which you need to write the driver/API yourself), you still don't need to care about those details. And you don't want to try to access the CAN bus without using a CAN controller at all...
If you want to pretend that you have a CAN interface, you may create a stub function which returns those three items: an ID, a data length and a 64-bit data buffer. This is basically what all CAN interface APIs will give you. And when transmitting CAN messages, you will use the same parameters (ID, length data).
PDOs are defined by their use of the CAN ID field. In theory the number of PDOs for a device is not really that limited, but the predefined connection set have only allocated a small number (four) of PDOs for each node.
The PDOs are standard CAN frames. As mentioned, the CAN ID identifies the PDO. In the predefined connection set (which most devices follow), the CAN ID of all messages consists of a functional part and a module-ID part (the module ID may be hard coded for the device, or configurable by dip switches for example). Bits 10-7 of the CAN ID is the function code and bit 6-0 is the module number. For example TxPDO1 from a device with module ID 0x10 would have CAN ID 0x190. The upper four bits of the 11-bit CAN ID, ((CAN_ID & 0x780) >> 7), gives you the function code (TxPDO1 = 3) and the rest of the bits,(CAN_ID & 0x7f), gives the module id (which in this example was 0x10). So if you read a message on the CAN bus with CAN ID 0x190, you would know that this was a PDO from the device with module ID 0x10.
(A simpler way to express this might be to say that TxPDO1 has CAN ID set to 0x180+<module ID>, TxPDO2 has CAN ID set to 0x280+<module ID>, etc.)
How you should interpret the data in the PDO depends on your device.
I suggest that you find a good CANopen tutorial. Unfortunately most of them make everything sound much more complicated than it really is. So look around until you find one that appears understandable.
There are many CAN interfaces that can run off a serial port - VSCOM, Vector, and many others. There are also free programs that allow you to send and receive raw CAN frames - CANhacker, etc. Google for a few of them.
What I haven't found is a free program that can do interpret CANopen - most are pay programs. The exception is Wireshark for Linux - it uses SocketCAN to pull in packets and can parse all the CANopen frames.
I run my CAN bus a 1 Mbit/s and use a VSCOM interface to monitor it on the serial port.
CANFestival is a good open source stack that ports easily to Linux as well as bare machines.