i'm using sierra wireless modems (compass 880/888, usb 308) and i'm trying to find an AT command that will tell the modem to connect to another cell (to another tower).
the reason i want to do it is because when i'm in a very crowded place, the cellular network is down, so i want to use the next nearest cell.
is that possible?
I doubt there is a command to do this; a handoff between cells is always controlled & initiated by the network.
Despite the fact that this decision is often made based on data that comes from the phone at the protocol level (relative signal strengths of the surrounding 16 cells) you can't force it as far as I'm aware - there would never be any point in doing so:
If a cellular device drops off it's network it will do everyting in its power to rectify the situation - if there is any cell station in range belonging to its home network (or one it can roam on) it will try to attach to it automatically, if not it will keep on looking.
If its dropped due capacity problems the the base station controller (the govenor of a bunch of cell sites) should already have tried to spread the load to any adjacent cells it knows its attached devices are in range of, if thats fails its a good bet that they are saturated too, so switching to them would be of no use.
I doubt that it's possible to connect to a neighboring cell. I'm not an expert, but as far as I know the antennas on the towers are quite directional. This means that the only antennas of the neighboring cell that are pointing at you are the ones on the far side of it. So even if that antenna would be enough to connect (which I doubt) you would most likely have a very bad signal, since the power of those towers is adjusted to end at (or maybe even before) the cell border.
Also, even if there is a command to connect to a specific cell, your device will notice that it connected to the wrong one and try to hand itself off to your current cell.
Related
Is it possible to disable GPS without disabling location services?
What I would like to do is essentially dumb-down location accuracy but removing gps function from my phone.
Im aware that I may not have accurate location - and im ok with that.
I just want to know if gps can be disabled and only use cell tower triangulation to determine my (approximate) location.
Thank you.
Igor
Your question is related to programming in the case of testing:
You cannot disable GPS with a iPhone/iPad setting while keeping cell tower location services,
but:
GPS is easily shielded by some metal foil, while GSM is very dificult to shield.
Try wrapping your phone into aluminium foil, you get in every super market.
That should shield GPS, while Cell Tower Triangulation still works.
That way I tested my Gps App.
You can't control the GPS directly. But you can specify the desired accuracy of the location, so you can specify a very large distance as acceptable, and stop updating location when you get it.
Also if you use region monitoring, the GPS is much less impacted (if at all), because it uses cell towers primarily.
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
We want to jam on 3G using our USRP 1 and GNU radio, is this possible ?
There are many ways to jam a signal, the easiest of which is obviously just to transmit over the signal you want to jam. Since USRPs can transmit, that essentially answers your question.
Please note, however, that transmitting (and thus jamming) signals in spectrum that you don't have permission to use is illegal in almost every country in the world. You will likely not get responses on how to do these things without giving details about what you are doing - nobody wants to enable illegal activity.
There are two ways to do this. The simple way is to simply jam the radio band in use. However, if you do this and the state takes exception, you have made it dead easy to find you. If you don't want to make high powered RF transmissions then you need to get a good book on UMTS and learn how a intercell handoff works when a mobile phone passes from one cell to the next. You could broadcast handoff signals causing user equipment to attempt to change cells. Since the new cell actually isn't expecting the user equipment the changeovers will fail and the phones will effectively jam each other.
If I were you I wouldn't do this without written official permission because harder to find isn't the same as impossible to find.
Further to this question, I'm looking for a device that will allow me to connect two USB hosts, while still being fully programmable. I would like something that can do the following:
Masquerade as an arbitrary USB device
Take input from a PC and do nothing but pass it on to the other host.
I've been looking for a microcontroller (preferably pre-assembled) that will allow me to do this, but have so far come up blank. Does anyone know of a controller (preferably cheap) that will allow me to do this?
Take input from a PC and do nothing but pass it on to the other host.
This is non-sensical from a USB perspective. USB is a host-based protocol: a device will never send data unless a host requests it first. Keep in mind here, 'host' and 'device' have specific meanings here within the protocol itself; you can think of a 'host' as the master and the 'device' as the slave. These roles are baked into a USB controller. There is no way to convince a standard USB controller in any given PC or peripheral to swap roles. There are add-in cards for PCs that are USB device controllers (making your PC act as a device), but 'cheap' is not a word I would use to describe them.
What you really are trying to do is create something that is a USB device to device bridge. So, alright, you need to have two USB(2.0) device controllers (maybe not that expensive, some micros already have to on-the-go controllers). Then you have to get them to pass something meaningful to each other. That's really hard because, as I mentioned above, hosts must tell a device to send data, and can send data to a device whenever it wants. Assuming a game controller shows up as a HID device (assuming the console doesn't listen for some weird, custom descriptor, and use some weird, custom protocol), interrupt pipes will be used to transfer data. This pipe is guaranteed to be polled at some minimum rate. So you have the console requesting data at some rate, which is not fixed, and a host-as-gamepad sending data at some rate. It's going to impossible for the two to sync up, so you'll need some kind of decent sized buffer on the gadget you're trying to create, which adds more $$ and more complexity.
USB is also pretty fast. In high-speed (USB2.0), frames are 125 microseconds long. That means you have to be completing requests at around 8KHz, which seems slow compared to the clock speed of a microcontoller, but keep in mind you have to be doing everything else at once. I'm not sure if there's a hobbyist-level microcontroller that's going to have everything you need, especially one for which you don't need to roll your own USB stack.
Try this chip -> FTDI 232 they are protocols chips, it will translate the data to i2c, spi, serial, whatever u want. nice, easy and cheap :) . FTDI firm, have even better ones (vinculum), with otg and everything u need but I would start with the FTDI232. U just need to use your favorite uC to do the work u want. ... on the other hand, u have to do a little board, maybe some soldering, :). good luck!
You will need $$$$ in equipment and $$$$$ in development work to achieve things the way you imagine. You should better tell us what do you want to emulate, and take a look here if someone has already done it for you. If not then use LUFA library with some bigger USB AVR that can behave as USB host and connect two of them (one as USB guest and the other as USB host) via some other protocol (I2C/SPI/UART).
In the meantime there is a great solution for this Problem. Using the FaceDancer Library together with one of the boards supported by this great piece of software (i.E. GreatFET One) you get exactly what you want:
The GreatFET One has two USB connectors: the first one is used to simulate ANY kind of USB Device, while the second one is used to forward all requests/responses received/send via the first connector.
Of course this tool requires that you know the USB protocol of the device you want to simulate. Although there are some code samples you still have to know what you are doing as soon as you customize them.
I'd like to start out with the Arduino to make something that will (preferably) dim my room lights and turn on some recessed lighting for my computer when a button or switch is activated.
First of all, is this even possible with the Arduino?
Secondly, how would I switch on and off real lights with it? Some sort of relay, maybe?
Does anyone know of a good tutorial or something where at least parts of this are covered? I'll have no problems with the programming, just don't know where to start with hardware.
An alternative (and safer than playing with triacs – trust me I've been shocked by one once and that's enough!) is to use X-10 home automation devices.
There is a PC (RS232) device (CM12U UK or CM11 US) you can get to control the others. You can also get lamp modules that fit between your lamp and the wall outlet which allows you to dim the lamp by sending signals over the mains and switch modules which switch loads on and off.
The Arduino has a TTL level RS232 connector (it's basically what the USB connection uses) – Pins 0 and 1 on the Diecimila so you could use that, connect it via a level converter which you can buy or make and connect to the X-10 controller, theirs instructions on the on the Arduino website for making a RS232 port.
Alternatively you could use something like the FireCracker for X-10 which uses 310MHz (US) or 433MHz (UK) and have your Arduino send out RF signals which the TM12U converts into proper X-10 mains signals for the dimmers etc.
In the US the X-10 modules are really cheep as well (sadly not the case in the UK).
Most people do it using triacs. A triac is like two diodes in anti-parallel (in parallel, but with their polarity reversed) with a trigger pin. A triac conducts current in either direction only when it's triggered. Once triggered, it acts as a regular diode, it continues to conduct until the current drops bellow its threshold.
You can see it as a bi-directional switch on a AC line and can vary the mean current by triggering it in different moments relative to the moment the AC sine-wave crosses zero.
Roughly, it works like this: At the AC sine-wave zero, your diodes turn off and your lamp doesn't get any power. If you trigger the diodes, say, halfway through the sine's swing, you lamp will get half the normal current it would get, so it lights with half of it's power, until the sine-wave crosses zero again. At this point you start over.
If you trigger the triac sooner, your lamp will get current for a longer time interval, glowing brighter. If you trigger your triac latter, your lamp glows fainter.
The same applies to any AC load.
It is almost the same principle of PWM for DC. You turn your current source on and off quicker than your load can react, The amount of time it is turned on is proportional to the current your load will receive.
How do you do that with your arduino?
In simple terms you must first find the zero-crossing of the mains, then you set up a timer/delay and at its end you trigger the triac.
To detect the zero-crossing one normally uses an optocoupler. You connect the led side of the coupler with the mains and the transistor side with the interrupt pin of your arduino.
You can connect your arduino IO pins directly to the triacs' triggers, bu I would use another optocoupler just to be on the safe side.
When the sine-wave approaches zero, you get a pulse on your interrupt pin.
At this interrupt you set up a timer. the longer the timer, the less power your load will get. You also reset your triacs' pins state.
At this timers' interrupt you set your IO pins to trigger the triacs.
Of course you must understand a little about the hardware side so you don't fry your board, and burn your house,
And it goes without saying you must be careful not to kill yourself when dealing with mains AC =).
HERE is the project that got me started some time ago.
It uses AVRs so it should be easy to adapt to an arduino.
It is also quite complete, with schematics.
Their software is a bit on the complex side, so you should start with something simpler.
There is just a ton of this kind of stuff at the Make magazine site. I think you can even find some examples of similar hacks.
I use MOSFET for dimming 12V LED strips using Arduino. I chose IRF3710 for my project with a heat sink to be sure, and it works fine. I tested with 12V halogen lamp, it worked too.
I connect PWM output pin from Arduino directly to mosfet's gate pin, and use analogWrite in code to control brightness.
Regarding 2nd question about controlling lights, you can switch on/off 220V using relays, as partially seen on my photo, there are many boards for this, I chose this:
As a quick-start, you can get yourself one of those dimmerpacks (50-80€ for four lamps).
then build the electronics for the arduino to send DMX controls:
Arduino DMX shield
You'll get yourself both the arduino-expirience + a good chance of not frying your surrounding with higher voltage..