I ran gCn client v0.9 for about two hours. It received everything just fine, but the system seemed to jam when I tried to send a longer message. I believe that there was a good deal of traffic on the network, and I'm sure that had something to do with it.

I also got various pictures of my bridge and uploaded them here. They should be okay, although there is some glare from the desk lamp in some of them.
Those are great photos, thanks for sharing! The Arduino can source enough current to make the transistors unnecessary in my bridge, but perhaps you used a higher-current RGB LED than me. Smile I'm concerned that you say it seemed to jam - how long of a message are we talking about? CALCnet Chat! can't handle messages longer than 253 characters for technical reasons, but I don't think Chat! actively forbids the user from entering longer messages; perhaps that's it?
I believe that it was a pretty long message I was sending - that could be what messed it up. As for the transistors, I need them because it's a common anode LED. So, as a warning to those building a bridge, be wary of RGB LEDs from RadioShack!
ahawesome wrote:
I believe that it was a pretty long message I was sending - that could be what messed it up. As for the transistors, I need them because it's a common anode LED. So, as a warning to those building a bridge, be wary of RGB LEDs from RadioShack!
Oh, that's an excellent point. Smile I'll add that warning to the gCn whitepaper actually, if you don't mind. Thanks for that.
No problem! I'll try to jam that bridge up again...

EDIT: For me, it looks like 52 characters is the magic number that will force the bridge to jam. I'll keep testing...
ahawesome wrote:
No problem! I'll try to jam that bridge up again...
That would be very helpful, I'd be interested in seeing what the jamming criterium/criteria is/are. Smile
It seems that a message of around 52 characters or more forces the bridge to freeze and report that it is jammed. Also, the terminal window that is running the gCn client software never reports sending any frames to the server (which is essentially what is expected). Are there any other CalcNet-enabled programs that might send relatively large frames?
ahawesome wrote:
It seems that a message of around 52 characters or more forces the bridge to freeze and report that it is jammed. Also, the terminal window that is running the gCn client software never reports sending any frames to the server (which is essentially what is expected). Are there any other CalcNet-enabled programs that might send relatively large frames?
The SpeedTest program (http://www.ticalc.org/archives/files/fileinfo/433/43374.html) uses 255-byte frames in the published version; I will give it a try. That's definitely bad, though; the bridge should be able to properly handle up to full-sized frames. What does the LED on the bridge do?
It gives me the alternating red/green sequence that, according to the whitepaper, means the transmission is jammed.
ahawesome wrote:
It gives me the alternating red/green sequence that, according to the whitepaper, means the transmission is jammed.
Correct. Interestingly enough, that means it's jammed trying to send something to the calculator rather than trying to receive from it. Which is probably indicative of the calculator trying to send at the same time the bridge is trying to send.
Interesting...

I've noticed that the Chat program doesn't receive anything while the user is typing in the text box at the bottom, so it seems like the bridge "holds" all of the data until the calculator is ready to receive it (you probably know what I mean - I can't think of a better way to explain it). I'm wondering if that has something to do with it...
ahawesome wrote:
Interesting...

I've noticed that the Chat program doesn't receive anything while the user is typing in the text box at the bottom, so it seems like the bridge "holds" all of the data until the calculator is ready to receive it (you probably know what I mean - I can't think of a better way to explain it). I'm wondering if that has something to do with it...
You have it exactly right. The calculator can receive one frame and hold it in the buffer while you're typing, but additional frames get held at the gCn bridge (or at the sending calculator, when you're dealing with CALCnet and not gCn). I'll try to track down this issue when I make more Obliterate progress, though.
Idea from IRC, placed here for consideration: if gCn's Chat! could be like Skype where you could call people by their IDs, except sans video and audio, that would be awesome. Very Happy Just an idea out into the wild. Wink
alberthrocks wrote:
Idea from IRC, placed here for consideration: if gCn's Chat! could be like Skype where you could call people by their IDs, except sans video and audio, that would be awesome. Very Happy Just an idea out into the wild. Wink
Instead of a communal hub, you mean? I suppose that could be implemented clientside; that would require a slight modification to the Chat program itself.
If you get to making them, I would totally buy one off you. I always dreamed of internet on calcs, but never thought it possible. You have advanced to god status now.
ACagliano wrote:
If you get to making them, I would totally buy one off you. I always dreamed of internet on calcs, but never thought it possible. You have advanced to god status now.
Haha, thank you sir, you flatter me. My Sparkfun order status for making $10 bridges instead of $30-$35 bridges is now at "Label printed", so hopefully I'll have results sooner rather than later.
KermMartian wrote:
ACagliano wrote:
If you get to making them, I would totally buy one off you. I always dreamed of internet on calcs, but never thought it possible. You have advanced to god status now.
Haha, thank you sir, you flatter me. My Sparkfun order status for making $10 bridges instead of $30-$35 bridges is now at "Label printed", so hopefully I'll have results sooner rather than later.


Did you figure out which FTDI components to get?
I decided to take BenRyves' suggestion and try bitbanging USB HID directly from the AVR, rather than dealing with serial (which Ben indicated is hard or impossible within the capabilities of an AVR). If it works, then bridges need only be a USB B female socket for data and power, an AVR, a crystal with two 22pF loading capacitors, and the Cn2.2 connections. You can of course then add a handful of LEDs and resistors for the bridge status and line status eye candy.
KermMartian wrote:
I decided to take BenRyves' suggestion and try bitbanging USB HID directly from the AVR, rather than dealing with serial (which Ben indicated is hard or impossible within the capabilities of an AVR). If it works, then bridges need only be a USB B female socket for data and power, an AVR, a crystal with two 22pF loading capacitors, and the Cn2.2 connections. You can of course then add a handful of LEDs and resistors for the bridge status and line status eye candy.


So presumably the gcnclient program will need to be extended to deal with a second type of bridge?
elfprince13 wrote:
KermMartian wrote:
I decided to take BenRyves' suggestion and try bitbanging USB HID directly from the AVR, rather than dealing with serial (which Ben indicated is hard or impossible within the capabilities of an AVR). If it works, then bridges need only be a USB B female socket for data and power, an AVR, a crystal with two 22pF loading capacitors, and the Cn2.2 connections. You can of course then add a handful of LEDs and resistors for the bridge status and line status eye candy.


So presumably the gcnclient program will need to be extended to deal with a second type of bridge?
Correct; that's why I haven't release v1.0 of the gcnclient software yet. I'll add an optional argument, like -a or something, to indicate an abridge bridge, if you will, so that existing Arduino users' scripts to run the client will still work properly.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 3 of 4
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement