This is a little off the beaten path. I've got a DLink DWL-G520 card I'm using under OpenBSD and it works fine. What I want to do is be able to access the radio part of it. Why? I want to use it in a radio telescope. It's a 2.4 GHz receiver with an external antenna connector. I want to connect some coax, some amplifiers, and an old TV dish and point the dish at the sky. It has an RSSI signal and variable RF gain (which it adjusts, from what I can find) so all I'd need to do is record those over time while pointed at a certain spot in the sky. I don't need to control the frequency really since most natural events are broadband.
I'm poking through the OpenBSD ath driver following nested structs but I don't want any of the normal network stuff, which is most of what the driver does. dmesg identifies it as an AR5212 which according to the Atheros PDF is always paired with an AR2112 radio. Is there any easier way than wading through PCI stuff to see what my options are? I need to turn the transmitter off so it doesn't fry my amps too. Trying to find low level documentation is about impossible from what I've seen. Ultimately I'd like to have this work with other WiFi cards too, but I'll start with this one. I've got a Cistron with an external antenna connector also.
Alan, ab1jx
Related
Im very new to contiki cooja.Im wanna simulate a waterflow meter in cooja simulator,is it possible ?My aim is to simulate a waterflow meter for tracking water useage.How can i do this in cooja?
The only thing you have to simulate is the device collecting the flow data. It could be a very simple device driver that mocks a flow sensor, by outputting a value that is your flow volume. Pick this value up from your application and process it accordingly.
For ideas on how to proceed have a look at these device drivers: "contiki dev".
Please, in future try to document the work you did prior to ask a question, as by now it looks like you didn't do any research on this topic.
Got a general question regarding the GPIOs on P9 of the beaglebone black. For instance, I would like to use the UART1 (RX and TX) for a R232 communication and use the I2C2 (SDA and SCL) for a sensor, using a C language application running on Linux. The problem is that the UART1 (RTS and CTS) signals are on those pins, can these features be deactivated (software)? and therefore use the UART1 and I2C2 at the same time?
PIN 19 : UART1_rtsn - I2C2_SCL
PIN 20 : UART1_Ctsn - I2C2_SDA
Next question, the same applies for SPI1 (CS0 and CS1), these pins are also on I2C2 (SDA and SCL).
PIN 19 : I2C2_SCL - spi1_cs1
PIN 20 : I2C2_SDA - spi1_cs0
So the general question : Can all 3 units, UART1-SPI1-I2C2 all run at the same time with no conflict on pins using the P9 header of the bbb?
Thank you very much for your answers
JH
It is technically feasable although when you start foraging into custom pin assignements you have to deal with alot of complexities to get everything up and working. There are many tables around the internet with the references as to which pins can do what. My favorite so far are these two : http://exploringbeaglebone.com/wp-content/uploads/resources/BBBP8Header.pdf, http://exploringbeaglebone.com/wp-content/uploads/resources/BBBP9Header.pdf
If you read these, you can see that each pin can take multiple different functions depending on configuration. These are set to the defaults by the linux kernel at boot time but you can modify the defaults using device tree overlays. The whole process is a little envolved for a single answer here but in short, to do what you want, you would need to modify and recompile the device tree overlay that the kernel loads for the device you want to change the pin assignements off.
Although there are some limits, for example, the beaglebone images are all configured to use I2C2 for identifying capes. So you can theoretically change it's pin assignments but then you shouldn't expect capes to be identified and configured properly when you do. In your example above, the UART1 and I2C2 work without conflict using their default configuration (UART1 only has Rx & TX by default). The SPI1 is a little more work. It's default configuration shares pins with the sound card (HDMI) that must be disabled to get it to work athough it does not conflict with ether UART1 or I2C2 by default.
Notice that each of these pins can have multiple functions but can only by one at any one time. Therefore, if a pin is set to use a given module (say UART1) it will not be affected by another module that can theoretically output on that pin with a different function mode. The kernel will complain if you try to use a pin for 2 functions simultaneously so you can try to load the overlays and see if it conflicts by default. Basically, if the kernel accepts to load the tree overlay, you can generally assume that it does not conflict with any other that is already loaded.
I think the other answer misinterpreted the question, and addresses configuration of the pins to perform a function of the possible mappings available to that pin. Yes, this is easily possible and is largely the point of the design.
With regards to the actual question, the answer is that it's possible but it's going to be very difficult and is most likely not feasible. And only one communication protocol will be able to be used at a time. Additionally, the spi pins are chip select pins, which require either an asserted or de-asserted state, so any kind of i2c clock or data signal will render the chip select non functional.
For i2c/uart, it would require reconfiguration of the pins and software mappings on the fly, and it will only be able to perform one of the possible functions at a time. It will also require software on all sides of the busses to be able to understand what mode the pins are in ie i2c or uart, with mutually separate and smart protocols so that none of the devices on the bus react undesirably to the garbage that will be on the bus when the bus is being used for another operation mode.
I am attempting to stream audio files from a server to iOS devices and play them completely synchronized. For example on my phone I might be 20 secs into a song and then my friend next to me should also be 20 secs into the song as well. I know this is not an easy problem to solve, but I am attempting to do so.
I can currently get them within one second of each other by calculating the difference in time between the devices and then have them sync up, however that is not good enough because the human ear can detect a major difference in a second and this is over WIFI.
My next approach is going to be to unicast the one file from the server and then have the all devices pick it up directly from the server and then implement some type of buffer system similar to netflix so that network connectivity would be a limiting factor. http://www.wowza.com/ is what I would use to help with that.
I know this can be done, because http://lysn.in/ is does it with their app and I want to be able to do something similar.
Any other recommendations after I try my unicast option?
Would implementing firebase help solve a lot of the heavy lifting problems?
(1) In answer to ONE of your questions (the final one):
Firebase is not "realtime" in "that sense" -- PubNub is probably (almost certainly) the fastest "realtime" messaging for and between apps/browser/etc.
But they don't mean real-time in the sense of real-time, say, as race game engineers mean it or indeed in your use-case.
So firebase is not relevant to you here and won't help.
(2) Regarding your second general question: "how to synchronise time on two or more devices, given that we have communications delays."
Now, this is a really well-travelled problem in computer science.
It would be pointless outlining it here, because it is fully explained here http://www.ntp.org/ntpfaq/NTP-s-algo.htm if you click on "How is time synchronised"?
So in fact, to get a good time base on both machines, you should use that! Have both machines really accurately set a time to NTP using the existing (perfected for decades) NTP synchronisation.
(So for example https://stackoverflow.com/a/6744978/294884 )
In fact are you doing this?
It's possible that doing that will solve all your problems; then just agree to start at a certain exact time.
Hope it helps!
I would recommend against using the data movement to synchronize the playback. This should be straightforward to do with a buffer and a periodic "sync" signal that is sent at a period of < 1/2 the buffer size. Worst case this should generate a small blip on devices that get ahead or behind relative to the sync signal.
I would like to write a web application that allows me to sync audio playback of an MP3 down to ~50ms, or close enough that the human ear can't detect the difference.
The idea would be that two or more smartphones could each be paired to a bluetooth speaker, and two or more speakers would play the same audio at the exact same time.
How would you suggest I go about setting this up, both client-side and server-side? I'm planning to use Rails/Ruby for backend, and iOS/obj c for mobile dev.
I had though of the idea of syncing to a global/atomic clock on the server, and having the server provide instructions to clients on when to start playing/jump in to an already playing track. My concern is that, if I want to stream the audio, that it will be impossible to load a song into memory and start playback accurately on the millisecond level.
Thoughts?
The jitter in internet packet delivery will be too large, so forget about syncing over the internet. However you could check the accuracy of NTP which is still used (I guess, I know that older UNIX's used it) by the OS when you switch on automatic date/time in Settings, but my guess is that it won't be good enough either. But perhaps the OS may also use other time sources like GPS; I'm don't know how iOS does it but accuracy within 20ms is not to be expected. You could create experimental app to check it out.
So, what's left is a sync closer to home, meaning between the devices directly. Of course you need to make sure that all devices haves loaded (enough of) the song, and have preloaded it in AVAudioPlayer or whatever you're using, to be able to start playing immediately. (It may actually not be the best idea to use higher level 'AVAudioPlayer` API's as it may give higher delays, and what more important higher jitter, than lower level API's.)
Here are three ideas (one device needs to be master triggering the start play, the others are slaves that are waiting for the trigger):
Use an audio trigger pulse, like a high tone of a defined length and frequency. Then use FFT to recognise this tone.
Connect the devices via GameKit Bluetooth and transmit the trigger on these connections.
Use the iPhone 4+ flash as trigger: flash in a certain pattern. This would require you to sample the video data which is quite doable and can be very fast.
I'm going with a solution that uses an atomic clock for synchronization, and an external service that allows server instructions/messages to be sent to all devices in close sync.
I'm writing a fairly low-level driver for a wireless card, and while most of the spec is fairly straightforward, I haven't wrapped my head around a single question yet:
If my station is in power-save mode and its receiver is turned off for an extended period (say, 10 seconds) between DTIM frames, and the access point is rebooted in the meantime so my association is lost, how can I detect this?
I'm aware that the most common case will be that synchronisation is lost thoroughly enough that I will miss a number of beacons and simply go back to the AP search afterwards, but if by some lucky chance I get to see beacons, is there some way to find out that this is a new "instance" of the same AP?
I can think of
a short(er) TIM field -- however I believe APs are allowed to shorten the TIM information if no traffic is waiting
the AP timestamp changing unexpectedly.
the "number of beacons to next DTIM" field changing unexpectedly.
Being a perfectionist, I'd like to know if there is an entirely reliable way to detect that the AP has been rebooted, rather than just putting together clues.
I would suggest that you look at the TSF in received beacon frames and
if it differs too much from the TSF you expected you send a NULL-data
frame to the AP. If the AP was rebooted it should respond with a
deauthenticate frame with reason "Class 2 frame received from
nonauthenticated STA".
I don't have any knowledge of wireless cards at that level, but I'd take a practical route and analyze the communication from the AP just leading up to the disconnect for a pattern that matches a typical shutdown sequence; for example, "no more traffic, a sudden loss of DTIM sync, and then an AP announcement".
Off the top of my head: maybe look into Kismet's AP detection and analysis code for an idea or two. I'd bet someone else has encountered this problem before.
Cheers!