Welcome to Open Circuits, Mzoran.
Thank you for making Open Circuits a better place by adding the USB soundcard based on a pic 18f2550 to Projects, and deleting lots of spam. I hope you enjoy reading OpenCircuits and sharing your knowledge with us.
A few tips:
- You can "sign" your contributions by typing four tildes "~~~~" at the end.
- Be bold with your editing. If you add information that really belongs on some other page of this wiki (or on some other wiki entirely), or you accidentally delete some crucial stuff, it's fairly easy for anyone to fix it. Please feel free to revert or otherwise fix-up any of my edits that turn out to be erroneous and/or misguided.
- Sometimes it is faster to delete spam (and restore what the spammer may have deleted) by pressing the "undo" button on the history "diff" page.
- We are all volunteers here.
Please feel free to talk about your electronics experiences here.
Welcome. --DavidCary 20:11, 12 October 2007 (PDT)
Open Circuits is a great place, but the spam is alittle out of control. Is it possible to simply block anonymous edits or block edits before the e-mail address is verified? Maybe even require only the first edit to be human approved. I noticed I was able to do edits before clicking on the account activation link. Like I said, the spam her is way out of control and I suspect it's being done by a few individuals who think they are being cool and funny.
I would also like to add that whoever is spamming the site isn't accomplishing much. The site adds the nofollow attribute to links so the sites will not be added to search engines or get their rank increased.
I finally checked out the 2 USB projects you mention on the projects page: USB Audio Streamer and PINGPONG-CDC. They look pretty cool. Thank you for telling me about them. --DavidCary 18:05, 8 December 2007 (PST)
The "ping pong" protocol looks very well thought through. There's only one teensy little suggestion I have. And by "teensy", I mean it's really a complicated idea that will only improve the system slightly, even in theory :-).
Instead of the master *always* transmitting at maximum RF output power, perhaps it could step down to a lower power. The simplest scheme: the master step down its power for each packet until it no longer hears a response from the slave; then it steps power back up. A more complex scheme would adjust both master and slave RF output power ... somehow.
Perhaps the master shouldn't always go through the fixed cycle of frequencies at a regular 200 ms each.
Imagine that you have 2 independent systems trying to communicate. By setting the magic 4 byte "Packet Identifier" different on each system, you can make sure that each slave only responds to its own master (and vice versa). However, it seems like it would be very easy for both masters to start transmitting on the first (same) frequency at the same time, then both start transmitting at the second (same) frequency at the same time, etc. Then either one is louder than the other, so one slave never hears its master -- or worse, they're both about the same, so the packet gets corrupted and neither slave hears its master.
It would be nifty if one master somehow noticed that the other master/slave system was transmitting, and decided to delay jumping to the next frequency for a little longer than the regular 200 ms. (But somehow avoid *both* masters always delaying the *same* amount, since that doesn't help any).
Ideally, the system would be scalable up to 53 different systems (53 masters and 53 slaves), each one with its own unique 4 byte "Packet Identifier". Ideally, if you had 52 such systems running, and then you turned on the 53rd master, eventually it would find the one frequency that no one else is using. Ideally, eventually (long after every system is transmitting on its own dedicated frequency at least *some* of the time), every master would transmit its SYNC packet at roughly the same time as all the others, on its own one of the 53 available frequencies. Then 200 ms later, every master would play musical chairs and switch to some other frequency at roughly the same time as all the others.
--DavidCary 20:38, 8 December 2007 (PST)
One mechism I can think of to do power adjustment would be for the slave and master to measure each other's signal based on the values from the RSSI indicator. This could be compared against the sensitivity of the receiver and adjusted untill the received power is just alittle above the intensity. I think your idea would work as well. Lower the power if the connection looks good and raise the power if too much packet loss is detected. In fact, the slave knows that the master will send Pings at regular intervals so that it can also detect the signal state. Maybe both ideas could be used in combination.
I've heard Bluetooth does something similar to your idea with detecting frequencies in use. It might be interesting to check into.
Some other mechanisms I see would be to take a hash of the four letter identifier to use as the starting position in the table. Another option would be to set a subchannel which would mean that the sender and receiver would use a completely different table( with different frequencies ) depending on the subchannel selection. I think Zigbee and Wifi might do something like the subchannel idea. Yet another option would be to have bigger tables that use the same 53 frequencies over and over. Each group of 53 frequencies in the table could use all of the 53 frequencies to provide guaranteed synchronization time. The master would broadcast the current position in the table in each SYNC packet.
I'll check more into some of these ideas.
Would it make sense to have a separate FHSS page on open circuits?
--Mzoran 17:30, 10 December 2007 (PST)
Yes, a FHSS page here on Open Circuits sounds great. The Wikipedia:FHSS article is educational, but my impression is that Wikipedia discourages the sort of "howto information" and "original research" that we want to talk about. Although NgARN : Next Generation Amateur Radio Network looks like it is even more supportive of all kinds of "original research" and "howto information", I'm not sure it's really geared to the kind of simple, low-cost, less-than-a-kilometer embedded systems we're talking about. Tell me if you find any other wiki that discuss radio protocols. (Or even wired protocols, for that matter). I hope we'll be able to move pages like FHSS to some other wiki when that is appropriate, and perhaps that wiki will have some pages that will be more appropriate to move to Open Circuits. --DavidCary 18:07, 11 December 2007 (PST)
I actually contributed some to the wikipedia page on FHSS, but I agree it would be nice to have a place to discuss the Nuts And Bolts of something like that which despite trying I was unable to find much in that way on that topic. I asked in the Sparkfun forum once about some implementation questions and I was simply told "Why are you doing that when you can buy an XBee?"
I have a few other projects pending but I'll start the topic as soon as I get some free cycles. --Mzoran