i was developing some application in java on a pi. One part of of the application exchanges data via modbus tcp, therefore i must implement a modbus tcp slave.
There are further points, that make that situation a little bit difficult. The server should support different user ids and modbus register maps that should not be built of thousands of fake registers.
First i experimented with jamod, which is good for the master part of my modbus application, but has problems with different user ids and i didn't figure out how to create registers with specified addresses.
Now i realized that the modbus slave must not be part of my java application. I'm searching a stabile running, testet software for raspbian, which fulfills my requirements. I found very much testing software implemented in python, c and many other languages.
Can you give me some advise, which software could be a good solution for me.
Related
I would like to communicate over USB using COAP protocol.
I am currently planning to use libcoap, it has examples but it is based on UDP server-client.
If I want to use USB, what must be done?
Thanks
Depends a bit on the deployment scenario, but in general I'd recommend using USB Ethernet inbetween (CDC-ECM). Then you can use CoAP over USB like you use it over any other network connection. (If you use RIOT for your embedded device and build the gcoap example on a board with native USB and enable the usbus_cdc_ecm module, you get that almost out of the box).
The large downside of this approach is that you are subject to the whims of the host OS's network setup. Probably it'll take up at least the IPv6 link-local interface so you can go ahead with requests to fe80::addr:ess (or even use link-local multicast to find your device), but there may be pitfalls.
There is the slipmux proposal which would do CoAP over serial, but a) I don't know implementations thereof, and b) it leaves you with similar issues of how to make sure your application can really find the right serial port.
It wouldn't be impossible to specify CoAP over custom USB commands (which would then be taken up by an application), but there'd need to be really good reasons not to just go through USB networking to justify them, and I'm not sure that the complexity of ensuring that your NetworkManager is set up correctly counts.
I want to scan the signal strength received from 3 AP.
I would be happy if that could happen every 300ms (max.500ms). I flashed OpenWRT on the routers.
I was seeking for a good tool to do that.
First I found iwconfig which worked, but only with networks that I was connected to. So I used iwlist (iw didn't work- maybe I need to update it?). Do you know how accurate is the output of it? Can I trust it?
After that, I came across the IOCTL. It looks really powerful* and professional. But is the output from getting the signal stregnth from a WIFI more reliable than the simple method like iwlist/iw?
*even too much powerful as I failed to compile any program I wrote using it
If you want to determine the signal strength of WLAN access points to which you are not connected, scanning is the right way.
The scanning is performed by the wireless network card with much or little "help" from the driver, depending on the design of the wireless card. There are cards (chipsets, to be more specific) that have their own processor and run their own firmware code independently from the host computer. On the other end, there are "stupid" cards where the driver on the host computer does most of the work.
Between the driver and the rest of the operating system, there is an interface (API) for sending commands to the driver and reading back information in a standardized way. With Linux, there are at least two different APIs. The older one is named Wireless Extensions, and the newer one is named cfg80211. Normally, a driver supports only one of the APIs. Most current drivers use cfg80211, but there may be older drivers that still use Wireless Extensions.
For each of the two APIs, there's a user-space tool (or family of tools) to use it. For Wireless Extensions, there is iwconfig (and iwlist, iwpriv etc.) For cfg80211, there is just iw.
So, the questions about the right tool depends on what API the wireless driver uses. To add confusion ;-), cfg80211 does some emulation which allows you to perform some Wireless Extension calls to drivers that use the newer cfg80211 API.
Regarding your questions about ioctl(): This is a generic method for communication between user-space and kernel-space in Unix operating systems. The old Wireless Extensions API uses ioctl(). The newer cfg80211 API does not use an ioctl()-based interface, but uses nl80211 instead.
To sum it up: whether to use iw/cfg80211/nl80211 or iwconfig/Wireless Extensions/ioctl depends on the driver or your wireless card.
Regarding your desired scanning interval, I would say that 300ms is rather short. This is because for a useful scan, the client needs to leave its current channel for a short time, switch to another channel and listen to signals from other access points on this channel. Since leaving its channel interrupts communication, these off-channel times are usually kept short and are carried out infrequently.
Calling iw <dev> scan or iwlist <dev> scan, respectively, will not necessarily cause a new scan, but may return an old (cached) list of access points. Depending on your wireless card/driver it may be (im)possible to enforce a new scan.
I developing one j2me application for read value from power meter over modbus protocol serial communication. I have code here to read Holding register but m not getting response from meter.so.
Is there any Modbus library for j2me?
Help me please.
Thanks in advance.
A known and mature MODBUS commercial library for Windows and Linux is for example, SuperCom. A commercial software library that offers MODBUS for serial and TCP data communications and includes many MODBUS variations too. Client (Master) and Slave functionality also included. And it offers many samples for well known compilers (more).
There surely exist more commercial solutions there.
My colleague and I are mining the GPRS MODEM market for a module suitable for use with embedded Linux. During the market scan, we see that several vendors highlight that their MODEMs include an embedded TCP/IP stack.
This makes me wonder: when we are using embedded Linux which already contains a TCP/IP stack and connects using PPP, will it make use of the stack included in the GPRS MODEM at all?
My current assumption is that the stack is included for use with tiny microcontroller OS that do not supply their own stack. Also some of the MODEMs allow for running small applications IN the MODEM baseband processor which could explain the embedded stack...
So: is the TCP/IP stack supplied by the GPRS MODEM superfluous when using it with an HL OS or did I overlook something?
It is almost certainly superfluous in your use case.
Most cellular modem products are cut-down versions of products designed for use in mobile phones. Obviously, in a phone application, the TCP/IP stack is required, along with a whole pile of other functionality.
A typical GPRS modem probably contains an ARM9 processor, and this is not greatly taxted running just the modem software. For many smaller applications it certainly provides sufficient performance to run the entire application (think of something like a vending machine indicating that it is nearly empty, for example), and a TCP/IP stack might be helpful here.
There is a slightly cynical possible explanation, too. Many mobile phone stacks have a bit more software coupling than their manufacturers would like to admit to, and it may turn out that it is simply not worth the effort to remove the TCP/IP stack.
In your application, it is almost certainly the best option to use the AT command interface (this is an extension of old-fashioned dial-up modem command set to allow you to fetch information such as signal strength, network status etc.
This is the EXACTLY same question I been asking myself these two days. ^^
After some study and asking around, I found this:
In the case of a smart phone such iPhone/android, TCP/IP are running on Application Processors(AP) as part of the OS. Baseband Processors(BP) are simply network modems (think of the 56k dial-up modem and PC setup in ancient time). Of course BP will be running mobile network stack(GSM, CDMA, LTE...) to hop on cellular network, but to AP, it's transparent and simply does modulation/demodulation work for the wireless network. Modems receives AT commands and can switch between command mode and data mode in operations. In data mode, the protocol between AP and BP is normally PPP over serial (! correct me if i am wrong here). So TCP/IP/PPP/serial.
Embedded TCP/IP stack found in some BP are meant to provide an entire abstraction for certain applications whereby network stack is not available due to system constraints or simply made to be simple. A TCP/IP stack is then very useful in BP. As you mentioned, some BP (e.g infenion) does have extra processing power for user application and/or network stack. AP, in this case, is even not needed. This is a typical setup of a function phone(such as Nokia brick). Extension of AT command sets are then provided by BP to create a socket or even a FTP connection.
I have an application where I have about 10,000 pieces of monitoring equipment across the US that periodically dials into a bank of 32 phone lines. I have two receivers of 16 lines each that answer the call and temporarily stores a small alpha string. I then have a computer that polls the receivers and parses the string and copies it to a database.
I am looking to replace the phone lines and the receivers with a voip solution and rewrite the software to parse the data string.
Any ideas on where to get started?
Tom's suggestion about Asterisk is a good one for the overall system.
However you will still need to decode the data sent from your remote equipment from an audio signal to a data signal. That task is what the "dem" part of Modem stands for (Modulate/Demodulate). Either you do this with a canned hardware/software package (as you are currently doing with a commercial modem) or you have to emulate the modem in software yourself which will be extremely tricky to code at the very least if you attempt it yourself (heaps of standards that you have to comply with for a general modem solution, plus the solution needs to work in real time)
For the software approach could start with this page Linmodems.org (just a something I saw on google prompted by your question). Alternatively do lots of searches on google for software modems. Getting someone else's code is the best approach for this sort of code :)
Whatever you end up doing I suspect it will be rather custom.
A good place to start is probably Asterisk PBX.
I take it you don't want to replace the modems at the client sites (the easiest thing on the server side would be each clients had its own IP software stack, and used its modem to call an ISP and establish an internet connection, and then talk to your server using TCP or UDP or HTTP or whatever).
Assuming that you don't have IP capability on the client sites, Googling suggests that the relevent technology is called "Modem over IP" or "MoIP" (which Wikipedia seems to be confusing with "Mobile over IP").
VoIP consists of SIP for signalling (e.g. for call set-up and call tear-down) plus some codecs (e.g. H.323) for traffic (encoded voice) while the call is established.
I'm guessing that MoIP can keep the SIP signalling, but needs to use some different codecs.
V.150 Modem over IP White Paper looks like an introduction to the technologies. I don't know what vendors there are.
I presume you are looking to find a way to do this without mofidying the modem hardware at your remote sites. If this is the case you will have to find or write signal processing software to demodulate the encoded signal from the modem. Fortunately, signal encodings on a modem are designed to be easy to do this with.
Maybe somebody makes software modem libaries that do this sort of thing. The other parts of the problem will be emulating the handshaking on the modem so it plays nicely with the remote sites.
If you can modify the software (really just the number to dial, but it would have to include the data you want to transfer) at the 10000 sites (not likely!), you could in theory use DTMF in the "dial" string to key the data over into Asterisk. Ok, more than a bit hackey, but it would avoid having to have a software modem. Note: you'd want a checksum!! (and maybe send it multiple times) And a way to tell the caller if it was received correctly. Like I said, hackey but cute.