Related
I am looking for a wireless communication technology for exchanging data between devices via sound in ultrasonic frequencies.It is possible to communicate with two mobile devices.I want to communicate a mobile and an embedded device.Is it possible?Any device is working with this protocol?
Of course it is possible. Back in the 1970's my TV remote control used ultrasound to change the channel and turn the TV off. The control was somewhat rudimentary IIRC a short press changed the channel up and a long press turned the TV off. It worked quite reliably for these functions.
Providing more functionality would require a more complicated modulation scheme which, as has been said in another answer, would be prone to interference from other sound sources. This probably explains why infra-red communucation signals are used in more modern remote control systems.
It is possible - why shouldn't it be? Smartphones are just embedded computers too. I imagine getting CE/FCC/etc certifications with such an embedded device will not be so easy. And production testing ...
But is it feasible? Probably not. Power consumption is a lot higher than with any RF-link, it's more susceptible to noise (quite literally) and the required components (microphone+speaker) are bigger than RF-components (antenna).
And then there's a whole bunch of other things you need to keep in mind when working with ultrasound, starting with the plastic design of the embedded device. But also things like the effect of ultrasound on people and their pets etc.
I'm working on an arcade cabinet that will be able to play various video game consoles (real hardware, not emulated.) There will be a PC inside to run a selection menu. I'll have to write that myself. I'll also need program a PLC which will do various things like control the relays which switch audio/video/controls between the PC and the various consoles, etc. I'll need help with those two tasks in time, but they are not what I'm working on right now.
What I'm working on as a starting point has to do with the controller encoding. Basically, the controls for each player consist of a few buttons and a joystick. These use momentary, normally-open contact switches, one for each button, and one for each cardinal direction on the joystick. Pressing the button, or joystick direction, closes the switch. The state of the buttons is then communicated to the console by an encoder.
The encoder has a connection for each button and joystick direction which is connected to 5 volts ("high") through a pull-up resistor. When a button or direction is pressed, a connection to ground is made through the momentary switch. When the encoder reads ground ("low") on a button connection, it knows that a button has been pressed and it communicates this to the console.
I already have all this working with the various consoles, but I've thought of some features that would be nice to add. This is where my current task comes in.
The first feature is button remapping. Some of these games were designed with controllers in mind, so when you use them with an arcade control panel, some of the buttons may not be where you want them. Some games allow buttons to be remapped via software, but others do not. My idea is to add a PLC in between the joystick and buttons and the encoder. I'll call this PLC a "pre-encoder."
The pre-encoder would read the states of the buttons on some input pins, then write these states back to some output pins, relaying them to the encoder. The advantage is that its programming could associate any input pin with any output pin, effectively remapping the buttons. Whenever a console is selected via the computer's menu, a button-mapping profile associated with a particular game could be selected as well, and forwarded to the pre-encoder.
Of course, the pre-encoder's routine which reads the buttons and relays their states to the encoder must repeat very quickly for smooth control. These games will be running at about 50 to 60Hz, meaning a new a video frame every 16.67ms or less. Ideally, the pre-encoder will be able to repeat this routine many, many times per frame to ensure the absolute minimum input lag. I want to ensure that the code and hardware selection is optimized to run as fast as possible.
The second feature is turbo buttons. Some games, especially arcade games, require a fire button to be pressed repeatedly every time you want to fire your gun, or your ship's cannons, etc, even if you have unlimited ammo. This seems unnecessary, and it will tire your fingers out pretty quickly. A turbo button is one that can be held down continuously, yet the game is being told that you are rapidly pressing and releasing it. This could be done in software for anything running on the PC, or with an analog solution like a 555 timer, but the best method is to synchronize the turbo button timing with the video refresh rate. By feeding the vertical sync pulse from the PC or video game console's video output to a PLC, it will know exactly how often a frame of video is rendered. Turbo button timing can then be controlled by defining, in numbers of frames, the periods when the button should be pressed and released. Timing information could also be included with the game-specific button profiles.
The third feature is slow buttons. Actually, this would probably only be applied to the joystick, but I'm referring to the switches for its cardinal directions as buttons. In certain games (it will probably only be used in shmups) it is sometimes needed to move your character (ship/plane) through very tight spaces. If movement is too fast in response to even minimal joystick input, you may go too far and crash. The idea is that, while a slow activation button is held, the joystick will be made less responsive by rapidly activating and deactivating it in the same manner as the turbo buttons.
I'm not sure if I want the pre-encoder itself to be watching the vertical sync pulse or if it will slow it down too much. My current thinking is that a seperate PLC will be responsible for general management of the cab itself; watching the "on" button, switching relays, communicating directly with the PC, watching the vertical sync pulse, etc. This will free up the pre-encoder to run more quickly.
Here is some example "code" for the pre-encoder. Obviously, it's just a rough outline of what I have in mind, as I don't even know what language it will be. This example assumes that a dedicated PLC will be used just as the pre-encoder. A separate PLC will be responsible for watching the vertical sync pulse, in addition to other tasks, like getting a game profile from the computer and passing some of that info to the pre-encoder. That PLC will know what the frame timing should be for turbo and slow functions, it will count frames, and during frames when turbo buttons should be disabled, it outputs high to a pin on the pre-encoder PCB, letting it know to disable turbo buttons. During frames when it should be enabled, it outputs low to that pin. Same idea with the slow buttons. There is also a pin which the pre-encoder checks at the end of its routine, so it can be told to stop and await a different game profile.
get info from other PLC (which got it from the computer, from a user-selected game profile):
array containing list of turbo buttons (buttons are identified by what input pin they are connected to)
array containing list of slow buttons (will probably only be the joystick directions, if any)
array containing list of slow activation buttons (should normally be only one button, if any)
array containing list of normal buttons (not turbo or slow)
array containing which output pin to use for each button (this determines remapping)
Begin Loop
if turbo pin is high
for each turbo button
output pin = high
next
else
for each turbo button
output pin = input pin
next
end if
if slow pin is high and slow activation button is pressed
for each slow button
output pin = high
next
else
for each slow button
output pin = input pin
next
end if
for each normal button
output pin = input pin
next
Restart Loop unless stop pin is low
If you've read all this, thank you for your time. So (finally), here are my questions:
What are your overall thoughts; on my idea in general, feasibility, etc.?
What kind of PLC should I use for the pre-encoder? I was originally thinking of trying an Arduino, but my reading indicates that it will be much too slow, due to its use of high-level programming libraries. I don't have a problem building my own board around another PLC.
What language should I use to program the PLC? I don't mind learning a new language. There's no time limit on this project, and I'll put it in whatever it takes to get the pre-encoder running as fast as possible.
What will I need to flash my program onto the PLC?
At run-time, how should these PLC's communicate with each other, and with the PC?
Am I asking in the right place; right forum, right section, etc.? Anywhere else I should ask?
Awaiting your response eagerly,
-Rob
I have some thoughts that might be useful to you:
What are your overall thoughts; on my idea in general, feasibility, etc.?
This project sounds like you want to cheat at Defender, like I used to do with a 555 timer chip in my Atari joystick when I was a kid.
The project is feasible but you will need a pretty fast PLC.
You might spend a lot of time making this work, like a quest.
What kind of PLC should I use for the pre-encoder? I was originally thinking of trying an Arduino, but my reading indicates that it will be much too slow, due to its use of high-level programming libraries. I don't have a problem building my own board around another PLC.
As I thought of what PLC might be fast enough, a few things came to mind.
If you use a PLC that has a task architecture, you can use an event to trigger a task on the v-sync pulse, and another event to trigger on console activity. If you use a PLC without a task architecture, the user might recognize the variable latency that will occur as the program scan moves in and out of phase with the v-sync and the activity in the game. This might not be true if the PLC is fast enough, say 1ms scan time.
Most inexpensive PLCs are never going to make it. The overhead and performance will keep most PLCs around 5-10ms per scan. However, a PC-based PLC might work well. So maybe a Beckhoff controller will work nicely. If you use something like a CX2000, it has Windows 7, USB, DVI for the user interface, and an Ethercat bus on the side to attach physical I/O cards for the controller and console connections. See about the software below. There are many non-PC-based PLCs that would work fine, but these will likely be expensive and harder to integrate.
The Arduino solution should work if you are using a fast enough model. But your development time will be higher because it doesn't come with anything but a blank screen and a bunch of libraries. Troubleshooting is much more of a pain-in-the-neck than PLCs that really shine. You'll need to plan carefully to get the Arduino to work. Also, hardware interfacing a microcontroller is harder and you'll have to manage debouncing the switches in your code. Every PLC has filtering in its inputs, and the variety of I/O makes design easy. But, the Arduino or other microcontroller is really the choice if money is an issue. A fast PLC can be real expensive ($800 to $20k, think around $1500). If you are going to build more than a few systems, the Arduino might be better.
What language should I use to program the PLC? I don't mind learning a new language. There's no time limit on this project, and I'll put it in whatever it takes to get the pre-encoder running as fast as possible.
IEC61131 is a standard for PLC programming languages. In the USA most PLCs are programmed in ladder logic because it is really easy to learn and quicker to troubleshoot and maintain in machinery. Structured text has its advantages too, particularly in performance. It looks like some amalgamation of basic/C/Java, easy to learn and looks almost like your pseudocode example. As for your project, I think it could be programmed in either language. I would never use the other IEC61131 languages for this task.
Beckhoff TwinCAT3 uses MS Visual Studio as the IDE, where you can write both the selection menu (in VB/C++/C#) and the PLC code (in IEC61131) in the same project. The runtime license for TwinCAT (on the CX2000 unit) runs in kernel mode, providing processing performance to Windows 7 whenever it is not doing something else more important. I've used a few CX1020 models and they were great performers. The scan times were around 5ms with a significant amount of code. Faster units will scan <1ms.
What will I need to flash my program onto the PLC?
PLCs don't "flash" like microcontrollers. Whatever software you use to write the software will have a way to connect to the controller. The term "go online" makes the connection. The terms "download" and "upload" refer to transferring the program between the development computer and the PLC. The term "online edit" refers to making code changes while the PLC is executing the code. When modern PLCs are powered down, they use a battery to copy program and user RAM to flash. When they power up, they copy the flash back to RAM. To make a connection to any modern PLC, you will use a USB or Ethernet cable.
At run-time, how should these PLC's communicate with each other, and with the PC?
You plan more than one PLC? A PLC connection to a PC is a complicated subject. The term "OPC Server" refers to some [expensive] software that lets your custom Windows PC application access memory in PLCs. The Beckhoff solution glues all that together nicely without buying more stuff. PLC to PLC communication is easier. The method is usually by ethernet and varies widely as to the details.
Am I asking in the right place; right forum, right section, etc.? Anywhere else I should ask?
Sure, there is some PLC activity on this forum, which appears to tend toward hardcore PC/Web/Mobile development. I come here for awesomely intelligent answers to my deeper software questions.
You could try plctalk.net, a forum that is a little more geared toward nuts-and-bolts engineers and service techs with wild connectivity and compatibility questions related to machinery and automation. You might get some blank stares about vertical sync pulses. Their skill sets revolve around an industrial paradigm, where reliability is probably their highest calling.
You might also ask questions about performance on an Arduino or Microchip/Atmel/ARM forums. If you tell them that a PLC is faster than their hardware, that will rile them up real good! They might tell you that you can get microsecond performance numbers, which you can if you are using hardware interrupts and lots of physical circuitry to make that a reality, and you are able to cope with the sleepless nights of troubleshooting.
-Dennis
I implemented an app that does real time broadcasting of music from one iphone to another based on Ray Wenderlich's tutorial about GKSession and Matt Ghallagher's tutorial on audio streaming.
Everything worked perfectly.. until we've decided to replace the poker game UI with that of our own. The result is that suddenly the networking throughput drops dramatically. Below is a profiler snap shot of the server
Here is a snapshot of the client of the original app
and here is a snapshot of the client of the app with the updated UI (host is the same as old one):
One thing to keep in mind is that we didn't just change the UI.. we also changed a bit of the networking code.. which is what I believe is slowing things down (I did a lot of performance testing ont the UI.. eliminating all the bells and whistles and the I got the same slow down)..
any ideas? some suggested that keeping a GKSession broadcasting availability slows thing down a bit.. I made sure that that's not the case in my app..
Update:
After looking at the network analysis (using instruments) it seems that there is a lot of network activity by some unknown process.. is there a way to detect that unknown process?
this is the screen shot for the good app:
and here is the screen shot for the bad app:
notice the difference between the two: in one other uses a lot more network activity than the other.. ideas?
Turns out that I had two different objects pointing to the same GKSession instance variable.. for some reasons that slowed things down.. the frustrating part is that GKSession is so opaque and so any debugging is pretty much guestimation. Lesson learned.. I'll just directly use bonjour next time.
I want to read how much data from 3G every app uses. Is this is possible in iOS 5.x ? And in iOS 4.x? My goal is for example:
Maps consumed 3 MB from your data plan
Mail consumed 420 kB from your data plan
etc, etc. Is this possible?
EDIT:
I just found app doing that: Data Man Pro
EDIT 2:
I'm starting a bounty. Extra points goes to the answer that make this clear. I know it is possible (screen from Data Man Pro) and i'm sure the solution is limited. But what is the solution and how to implement this.
These are just hints not a solution. I thought about this many times, but never really started implementing the whole thing.
first of all, you can calculate transferred bytes querying network interfaces, take a look to this SO answer for code and a nice explanation about network interfaces on iOS;
use sysctl or similar system functions to detect which apps are currently running (and for running I mean the process state is set to RUNNING, like the ps or top commands do on OSX. Never tried I just suppose this to be possible on iOS, hoping there are no problems with app running as unprivileged user) so you can deduce which apps are running and save the traffic stats for those apps. Obviously, given the possibility to have applications runnning in background it is hard to determine which app is transferring data.
It also could be possible to retrieve informations about network activity per process/app like nettop does on OSX Lion, unfortunately nettop uses the private framework NetworkStatistics.framework so you can't dig something out it's implementation;
take into account time;
My 2 cents
No, all applications in iOS are sandboxed, meaning you cannot access anything outside of the application. I do not believe this is possible. Neither do I believe data-traffic is saved on this level on the device, hence apple would have implemented it in either the network page or the usage page in Settings.app.
Besides that, not everybody has a "data-plan". E.g. in Sweden its common that data-traffic is free of charge without limit in either size or speed.
I'd like to start messing around programming and building something with an Arduino board, but I can't think of any great ideas on what to build. Do you have any suggestions?
I show kids, who have never programmed, or done any electronics before, to make a simple 'Phototrope', a light sensitive robot, in about a day. It costs under £30 (GBP) including Arduino, electronics and off-the-shelf mechanics. If folks really get into mobile robots, the initial project can grow and grow (which I feel is part of the fun).
There are international robot competitions which require relatively simple mechanics to get started, e.g. in the UK http://www.tic.ac.uk/micromouse/toh.asp
Ultimate performance require specially built machines (for lightness) , but folks would get creditable results with an Arduino Nano, the right electronics, and a couple of good motors.
A line following robot is the classic mobile robot project. The track can be as simple as electrical tape. Pololu have some fun videos about their near-Arduino 3PI robot. The sensors are about £1, and there are a bunch of simple motor+gearbox kits from lots of places for under £10. Add a few £ for motor control, and you have autonomous robot mechanics, in need of programming! Add an Infrared Remote receiver (about £1), and you can drive it around using your TV remote. Add a small solar cell, use an Arduino analogue input to measure voltage, and it can find the sun. With a bit more electronics, it can 'feed' itself. And so it gets more sophisticated. Each step might be no more than a few hours to a few days effort, and you'll find new problems to solve and learn from.
IMHO, the most interesting (low-cost) competitions are maze solving robots. The international competition rule require the robot to explore a walled maze, usually using Infrared sensors, and calculate their optimal route. The challenges include keeping track of current position to near-millimeter accuracy, dealing with real world's unpredictably noisy environment and optimising straight-line speed with shortest distance cornering.
All that in 16K of program, and 1K RAM, with real-time interrupt handling (as much as 100K interrupts/second for some motor systems), sensor sampling, motor speed control, and maze solving is an interesting programming challenge. (You might make it 'easy' with 32K of program, and 2K RAM :-)
I'm working on a 'constrained' robot challenge (based on Arduino) so that robot performance is mainly about programming rather than having a big budget.
Start small and build up to something more complex. Control servos. Blink LEDs. Debounce inputs. Read analog sensors. Display text on an LCD. Then put it together.
Despite the name, I like the "Evil Genius" book for PIC microcontrollers because of the small, easily digestible projects that tend to build on one another. It is, of course, aimed at PIC programmers rather than the Arduino, but the material covered will be useful no matter what you're developing on.
I know Arduino is trendy right now, but I also like the Teensy++ development board because of its low price-point ($24), breadboard-compatible PCB, relatively high pin count, Linux development environment, USB connectivity, and not needing a programmer. Worth considering for smaller projects.
If you come up with something cool, let me know. I need an excuse to do something fun :)
Bicycle-related ideas:
theft alarm (perhaps with radio link to a base station which is connected to a PC by Ethernet)
fancy trip computer (with reed switch or opto sensor on wheel)
integrate with a GPS telematics unit (trip logging) with Ethernet/USB download of logged data to PC. Also has an interesting PC programming component--integrate with Google Maps.
Other ideas:
Clock with automatic time sync from:
GPS receiver
FM radio signal with embedded RDS data with CT code
Digital radio (DAB+)
Mobile phone tower (would it require a subscription and SIM card for this receive-only operation?)
NTP server via:
Ethernet
WiFi
ZigBee (with a ZigBee coordinator that gets its time from e.g. Ethernet or GPS)
Mains electricity smart meter via ZigBee (I'm interested now that smart meters are being introduced in Victoria, Australia; not sure if the smart meters broadcast the time info though, and whether it requires authentication)
Metronome
Instrument tuner
This reverse-geocache puzzle box was an awesome Arduino project. You could take this to the next step, e.g. have a reverse-geocache box that gives out a clue only at a specific location, and then using physical clues found at that location coupled with the next clue from the box, determine where to go for the next step.
You could do one of the firefighting robot competitions. We built a robot in university for my bachelor's final project, but didn't have time to enter the competition. Plus the robot needed some polish anyway... :)
Video here.
Mind you, this was done with a Motorola HC12 and a C compiler, and most components outside the microcontroller board were made from scratch, so it took longer than it should. Should be much easier with prefab components.
Path finding/obstacle navigation is typically a good project to start with. If you want something practical, take a look at how iRobot vacuums the floor and come up with a better scheme.
Depends on your background and if you want practical or cool. On the practical side, a remote control could be a simple starting point. It's got buttons and lights but isn't too demanding.
For a cool project maybe a Simon-style memory game or anything with lights & noises (thinking theremin-style).
I don't have suggestions or perhaps something like a line follower robot. I could help you with some links for inspiration
Arduino tutorials
Top 40 Arduino Projects of the Web
20 Unbelievable Arduino Projects
I'm currently developing plans to automate my 30 year old model train layout.
A POV device could be fun to build (just google for POV Arduino). POV means persistence of vision.