As you know we can use our ADSL modems to send/receive data with high bandwidth through our phone line to/from ISP servers. I'm interested to write a program to use this capability of ADSL modem to send/receive files directly between computers (like Hyper Terminal application which was used for 56k serial modems). Is it possible? Also I want to know does it need governmental support or not? :)
Best Regards
While this is definitly possible (at least with the Alcatel ADSL modems), it is not worth the hassle. Some random points - please mind that this is written from a european POV, things might be a little different in the USA.
Carriers are not amused, if you change the configuration of your modem. Some will call it "hacking" and disconnect you.
It is not possible, to use the modem for both (Internet access and file transfer) at the same time.
It won't work between modems on different carrier networks or even in different LM segments of the same carrier - the ADSL signal is terminated at the multiplexer in your carrier's LM switch. It does however work between modems attached to the same multiplexer.
For your problem, the solution ist to use a TCP connection instead of a fake serial - even HyperTerminal can do that AFAIR
Related
I am new to Wireshark and capturing packets and all Stuff. Let me get it to the straight.
I have a hardware which outputs its data over Ethernet using a UDP Broadcast. I Can directly plug a Ethernet Cable to a In-line RJ-45 Coupler (attached to the hardware) and my PC Running Wireshark.
REQUIREMENTS : I need to Capture RAW Data which my hardware is broadcasting so that it can be given to other team so as to know the format in which it is providing for further post processing.
What I Did : Initially , I connected the Ethernet Cable from my home and Started capturing the packets which didn't make any sense to me.
Can you please point out if I am going in correct direction ? Sorry if its a very basic question, but raw data from the hardware is important for my further tasks....
As far as any software can understand a wire you will always get a packet. Between you (in front of a computer) and the cable in the in the RJ-45 jack sits a NIC (network interface controller, i.e. your network card).
Your Ethernet NIC will read the current on the cable (in manchester encoding for ethernet) and synchronize itself to any Ehternet traffic on that cable. What does "synchronizing" mane in there? In front of any Ehternet traffic come 64 alternate bits of 0s and 1s which are meant to synchronize the clocks on both communicating NICs. Without proper clock synchronization some data may be misinterpreted.
But why I am talking about clock synchronization? Because if you want the data as RAW as it is on the cable you will not get it. A NIC will never send any synchronization bit to the rest of the computer, therefore it is absolutely impossible to read exactly what is on the cable by using software.
On the other hand I find hard to believe you want the RAW data as RAW as that. After the synchronization bits come an Ethernet encapsulated packed. Yup, Ethernet uses packets. They're link layer packets (layer 2 in OSI).
And wireshark gives you exactly that (in most cases, see note at the end for two exceptions to this rule): every Ehternet packet that the NIC understands, manages to sync, and manages to read without collision is sent to the kernel and then read by wireshark. A cable has electrical interference and has no provision against collisions (it's just a piece of cooper!) therefore the NIC abstracts things like interferences and collisions.
I'll repeat it once more: After abstracting the synchronization bits, sender collisions (which turn the cable into one huge interference) and plain interferences; all that remains is a stream of packets, one after the other.
Extra Notes
NICs sometimes do ignore some Ethernet packets: packets that are not directed to their MAC. This can be changed by enabling promiscuous mode (available in most NICs). This is irrelevant for broadcast packets.
There are exception to the rule of wireshark getting all the traffic coming from the NIC:
If the traffic comes incredibly quick, wireshark may drop out of kernel schedule and not see some packets. It happens, nothign can be done about it.
If you listen on all interfaces (as opposed to selecting a single interface to listen at), wireshark will strip the Ethernet (or Wifi) headers. This is a wireshark hack needed to make output files uniform (and possible to be read by other applications).
TL;DR, wireshark output (pcap) is pretty much just the stream of packets that it got from the NIC, one after the other. That is as RAW as you can get with software.
I encounter a problem when I'm trying to use a Ubuntu laptop computer to connect to two Sony A6000 through WiFi in the same time.
On that laptop there are two WiFi adapters, one is embedded (say, Wifi-A) and the other is an Asus USB-N13 ProN USB
dongle (say, Wifi-B).
Using Sony Camera Remote API I can successfully control these two A6000 (say, A6000-A & A6000-B)
through these two Wifi adapters, provided only one camera is connected a time. For example, either using Wifi-A to control to
A6000-A or A6000-B, or using Wifi-B to control A6000-A or A6000-B, will work.
I think this proves both the cameras and Wifi adapters hardware function correctly, and any combination of Wifi adapter and
camera works fine, too.
However, it will be different if I try to connect and control both cameras in the same time. The connection to both cameras
is OK (though sometimes not very smooth), but controlling them is not.
Here is a list of the experiment steps:
Wifi-B connects to A6000-B. Then Wifi-B gets IP address 192.168.122.166
Wifi-A connects to A6000-A. Then Wifi-A gets IP address 192.168.122.165
Send M-SEARCH request to Wifi-A and get response from A6000-A. Then get
Device Description XML file from A6000-A successfully.
Send M-SEARCH request to Wifi-B and never get response
I'm wondering if such configuration (One laptop + two Wifi adapter + two A6000) violates any design consideration
of A6000? For example, because both cameras use the same IP address 192.168.122.1 for themselves?
I'll appreciate if any one could comment on this issue.
Thanks in advance!
Xavier
After doing experiments for many days, I'm sure this symptom is caused by the IP address conflict (both of them are 192.168.122.1) of these two A6000.
As I can't find a way to change them, my optimal solution under such configuration (one laptop + two Wifi adapter + two A6000) is to make use of Linux Network Namespaces. Moving Wifi-B to a new Network Namespace does solve this issue, because every Network Namespace has its own network stack. Now I can freely access both of these A6000 from my laptop.
I hope this answer is helpful to anyone who encounters a similar problem.
There isn't any design consideration that would block this from working. Unfortunately we cannot offer any other troubleshooting suggestions.
I have an old hub that sucks, so I converted it to a USB-tripler by soldering all of the input 4 wires to the corresponding wires on the output connectors. I had to do this because modern devices require 2.0 or 2.8 volts on d+, and refuse to charge if d+ is shortened or not connected. It works well charging three devices from a 1a wall adapter.
But if someone accidentally connects this to a PC port, what will happen? Well if there is only one device, it would be detected no problem. But if two devices are wired to the same port, how dangerous is that?
I would prefer the first connected device to be identified in the system, while the second connected devices just get the power.
One of the first steps in USB enumeration is to send a reset signal by driving D+ and D- low. All the devices plugged in will see the reset and think it was intended for them. After the reset they will each think they have address 0 and respond to requests to that address. The result will be multiple devices trying to drive the bus at the same time, for a brief period before the host gives up.
I think it wouldn't damage anything, but you will be causing a short circuit for a few microseconds which is bad.
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.
I'm trying to create an embedded outdoor display of bus arrival times at my university. I'd like the device to utilize my school's secured WiFi network to show arrival time updates determined from a server script I have running.
I was hoping to get some advice on the high-level operation of this thing -- would it be better for the display board to poll a hosted database via the WiFi network or should I have a script try to communicate with the board directly over 802.11? (Push or Pull?)
I was planning to use a Wifly or WIZnet ethernet board in combination with a wireless access hub. Mostly inspired by this project: http://www.circuitcellar.com/Wiznet/winners/001166.html Would anyone recommend something else over one of the WIZnet boards? I saw SPI/UART options and thought these boards could work with an AVR platform.
And out of curiosity -- if you were to 'cold start' this device (ie, request a bus arrival time by pushing the display's on button) you might expect it to take 10-20 seconds to get assigned an IP and successfully connect to the database, does that sound right?
I'd go pull. In fact, I'd have outdoor display make http or https requests of the server. That way the server could tell it how long to show a given set of data before polling for a new one using standard http page expiration.
I think pull would make it easier to have multiple displays, and to test your server as well. I've also got a gut feeling that this would make your display more secure. Someone would have to hack your server to hijack your display.
There's a very cool looking Arduino-targetted product called the WiShield. Seems super easy to use and he provides some source code. It uses SPI for host communication. If you're not interested in going the Arduino route, I'm sure the source code wouldn't be too hard to port to something like avr-gcc. Check it out, might save you some time and headaches for $55. Worth checking out anyway.