i need to write a battery model that is able to discharge and charge at specified times in a simulated wireless sensor network in omnet++ using inet modules.
as far as i got i did understand that i need to build an IBattery implementation to provide battery specifications and maybe recharging capabilities and some other module/way to begin discharging and charging periods.
one idea was to implement the IPowerControl interface but it does not seem to have control over the type of event (e.g. charging or discharging)
what should i look for? i am a bit overwhelmed by inet source code dimension and got lost...
Related
I am currently working on the design of a measurement system. It has a three instruments mounted on a pan/tilt head, but only one serial line from the instruments to the Beaglebone Black (BBB) that controls everything. Instrument A and B are similar (use the same commands and module). I'm using Python to control everything. During testing, I had additional cables so that I could wire each instrument to a separate port on the BBB, but that is not possible in the final setup.
Since I needed some processing capabilities on top of the pan/tilt head anyway, I'm using a PIC24 device to connect all instrument serial connections to.
My idea is to multiplex the 3 serial connections, for instance by adding a prefix A_/B_/C_ to the commands/replies.
This I can do.
Communications and processing for instrument A and B is done by the same Python module, which has a function measure() that takes the serial port (ie. /dev/ttyO4) as one of the parameters. I'll obviously need to adapt this.
I need to find a way to allow different modules to access three "virtual" ports, with the choice of either stream A/B/C.
So in short: I (think I) need some kind of class/... that opens the serial port and multiplexes/demultiplexes three streams. Instrument A and B are not to be used simultaneously, but A/C and B/C can be used at the same time. Timing is not critical, a couple of hundreds of milliseconds delay is not an issue.
One option would be to use a second PIC to do the reverse of the microcontroller near the instruments, but I suppose this should be possible in Python as well...
I think the elegant solution is to add some code for your PIC to work as a Modbus slave.
There seem to be good efforts already done, so maybe you can use something like this as a starting point.
You can have the three UARTs connected to the sensors continuously writing to several Modbus registers and query those from your BBB with something like pymodbus or pylibmodbus.
It will also be possible to use other buses/protocols like CAN, but if you run Modbus directly on the TTL UART (instead of over RS485, which you won't need unless you have long distance or a noisy environment) you don't need any additional hardware. You will have to modify the firmware on your PIC and write some more lines of Python on your BBB.
But if you want to learn something new (assuming you don't know already), Modbus is quite an easy and useful protocol to add to your toolbox. It's still very popular and open (the spec is publicly available and you have tons of info and code).
EDIT: I'm keeping my first answer as a reference for others, but the question did not refer to sharing the same physical cable for multiple ports so what I wrote here is not really useful somebody misunderstands it the same way I did.
This question has come up a number of times, see for instance Receiving data from multiple devices using parallel wired RS232
Serial lines are not intended to be multiplexed, if you decide to follow this route I think you'll get many headaches.
Is there a reason not to use a multipoint protocol like RS485, SPI...? I'm sure you'll be able to find one that works for your needs. For RS485, for instance, the
investment in new hardware would be minimal and the software side would be a piece of cake.
I know I'm asking a dumb question, but I'm quite of a zwave/openzwave beginner, so I wanted to get some help on that.
My zwave network is already up, and I have two nodes:
the key itself to control the other nodes
a sensor for temperature and humidity (the ST814, from Everspring)
Now, I want to display the temperature and the humidity in my console, but I'm not really understanding how it works. From what I understood, I need to configure the auto-report of my sensor (doc is here, see page 6), and get the notifications every X minutes, but I'm not sure.
Does someone already did that or know how to do it?
Thank you a lot,
Maxime
Imagine there's a room full of people from Sweden, and they're all talking to each other in Swedish. Even though you can hear what they're saying, it doesn't mean anything to you because you don't speak Swedish. If you had the ability to speak Swedish, you would understand exactly what was going on.
Now imagine there's a network full of devices and a controller that all speak Z-Wave. Sensors are reporting temperature and humidity at regular intervals to the controller. But, even though you can hear what they're saying, it doesn't mean anything to you because you don't speak Z-Wave.
OpenZWave is a library that enables you to understand and speak Z-Wave. You can use it to create software that listens to the conversations, decides what action to take and even barks out orders in Z-Wave to devices (e.g., motion detection -> call the police). OpenZWave comes with sample applications that show you how to construct your own home automation software using the OpenZWave library. You can also use a software package such as Domoticz, HomeSeer, OpenHAB or SmartThings. These applications provide a broad set of home automation features and functionality so you don't have to program them yourself.
To use the least amount of battery, a device such as the ST814 spends most of its time sleeping. At user-defined regular intervals (for example, every hour), the device wakes up, reports the temperature and humidity to the controller and checks to make sure there are no other commands or requests waiting for it. Then it goes back to sleep. You determine how often the device wakes up and can set it according to the instructions you referenced.
If you want to intercept the temperature and humidity report from the ST814 to the controller and output it to the console with OpenZwave, you need to write some code or use someone else's program. The latter is easier, but might not enable you to do exactly what you want to do. Using OpenZWave is harder, but provides the capability to do just about anything you want to do.
I am posting here concerning the emulation of computers on the local network, without destroying the local network.
When a computer connects to wifi on your local network, the computer can be seen in the "Network" section of Explorer(on Windows) and can be addressed via internet protocol.
My Goal: I would like to create a program such that I could receive streams of data from a remote computer via radio waves. The communication would be full duplex, there would be a transmitter and a receiver on both ends.
My Idea: I would like to utilize Qt to create an application which would receive and demodulate the radio waves like sound (through OpenAL buffers) which would act similarly to a driver program for the emulated computer connection, without destroying my connection to the local network. In this way, I believe that some truly novel things could be done, as I could for instance, use PuTTY one the emulated connected computer remotely while browsing my local network and the internet from my "base" computer.
Extended explanation: I want to perform a weather balloon project, sending a small computer (likely Raspberry Pi3) via a weather balloon to the far reaches of our atmosphere. One of my worries is being able to communicate with the device, such as receiving locational (telemetry) data in real time and being able to (potentially) retrieve arbitrary data in real time.
I understand that I may very well be approaching this question in the wrong way. There are probably existing systems out there that grant telemetry data and some arbitrary means to transfer file data, of which I am unaware. But from what I have seen, I also cannot find a device that utilizes this approach (packet radio emulation of a computer on the network). I have a personal curiosity towards this approach, and thusly will accept the answer which follows most in line with this approach.
P.S: Video which inspired this idea:
https://www.youtube.com/watch?v=Ueb5JG0dCL8
What you're trying to do is called software-defined radio, and is rather popular. Modern computers, even little ones, are more than powerful enough to do the modulation/demodulation entirely in software.
There's very little left for you to do other than designing the RF channel, purchasing often open-source hardware, and using existing open-source SDR implementations out there. The input/output to your Qt program would be either a QIODevice-like data stream that you'd couple to the SDR library's data scrambler/descrambler, or a packetized data stream that you could run some higher-level protocol on.
Do note that unless you limit yourself to an industrial license-free band, you are likely to need an FCC license to operate the transmitter, and an FAA license to launch the balloon.
Your question is essentially off-topic here. It probably belongs on amateur radio stack exchange under the [sdr] tag.
If you're thinking of implementing a complete WiFi stack using SDR, I'd like to discourage you: it's patent-encumbered up the wazoo, so no open-source implementations exist, and the sheer amount of standardese you'd have to wade through to do a compliant implementation is staggering. We're talking on the order of 5,000 pages of standardese, where almost every other sentence is important so if you ignore it, you're not compliant.
I read some questions here but couldn't really find the specific problem I'am faced with here...
I need to implement a "DeviceCache" in a particular project which caches all device-names found in /proc/net/dev .
The Language is C/++
So I thought about a seperate thread looking every X seconds in the directory mentioned above but was encouraged to find a more direct way.
How can I register a method of my process to the device manager of linux?
Is there a similar way like events/signals?
I looked in other sites but couldn't find any helpful code... Im relatively new to Linux-programming but willing to learn new things :)
Based on your comments, what you really want is to track which network interfaces are operational at any given time.
The only true way to determine if a network interface is up is to test it - after all, the router on the other end may be down. You could send pings out periodically, for example.
However, if you just want to know if the media goes down (ie, the network cable is unplugged), take a look at these SO questions:
Linux carrier detection notification
Get notified about network interface change on Linux
If you just want to be notified of the actual hardware-level registration of interfaces (eg, when a USB NIC is plugged in), you can use udev events if your platform has udev; otherwise, I believe there's another netlink category for hardware addition/removal events.
Please let me know how to decode infrared remote control code using c or c++.
I suppose your question is vague because you absolutely don't know where to start.
If you don't have a infrared receiver, here is a blog is used some time ago to learn how to build one. I hope you have some talents in electronics. Otherwise, it's time to learn ! :D
If you managed to build it (or have another known-working receiver), you can then take a look at LIRC, an open-source project which is compatible with the suggested device.
Well, I don't know about C++, but here it is in C#:
void ReadRemote()
{
while(!Console.KeyAvailable)
Console.Write(DecoderClass.ReadIR(IRType.TVRemoteControl));
}
Different manufacturers use different encoding schemes, different timing, and even different modulation frequencies. A typical IR receiver sensor performs the demodulation in hardware so that it outputs a logic pulse sequence rather than an OOK modulated signal. The receiver needs to match the transmitter modulation frequency. If you want to receive multiple modulation frequencies, you would have to use a simple IR photo-diode and provide your own OOK carrier detector circuitry for each modulation frequency of interest, or use multiple receivers.
Once you have the demodulates pulse sequence, it is a simple matter of decoding it according to the specific manufacturers encoding scheme. I have only ever done this for a Sony SIRC remote to use it as a robot controller. Where the sensor triggered an interrupt and the pulse timing was latched on each interrupt. If your device has input capture and compare timer hardware you could reduce the overhead and increase accuracy (although this is probably not necessary).
There are lots of resources on the subject for different protocols and manufacturers here
There are some applicable standards, but no manufacture has to adhere to them, and there is more that one. RC-5 and RECS 80 are two such standards that are fairly common.
Either buy some hardware that does it and make C or c++ api calls (lirc for example). or if you are interested in decoding the protocols and doing it with software instead of hardware then you want to use a microcontroller.
It is fun and easy and I recommend it as a first microcontroller project. There are a handful of popular protocols, most are a variation on a couple of themes. Basically you get a receiver which you can get from radio shack, although the amount of what used to be radio components at radio shack (maybe that is why they are changing the name to the shack) are much fewer and buried in a small drawer in the back of the store, soon to be gone. Anyway get a receiver there or digikey or mouser, a microcontroller, count the number of clock ticks between rising and falling edges (the receiver has removed the ~40Khz carrier frequency) compare those times to the expected protocol and determine the ones from zeros. Transmitting with just a microcontroller and an ir led can be done but is a little trickier because you need to do the modulation. A single and gate outside the microcontroller along with the modulation clock and/or a timer generated clock is much easier, but requires extra hardware.
The multi protocol receivers are likely not to be as good as a specific protocol receiver, in the same way that gcc is not very good at any one platform, but pretty good across all the platforms. Building your own is fun, educational, and generally results in a better receiver, although you wont be able to match the price of the mass produced products. Part of the problem also has to do with the carrier frequencies vary and ideally you want to choose the receiver that matches the carrier frequency for the protocol you are using. It makes a difference, for example instead of having to be 8 feet away you can be 30 feet away. Also it may work at 3 feet away but not one foot or three inches away. That sort of thing. cable and dish and other universal remotes generate all of the protocols so you are free to pick and choose depending on what your project is.