We have tried several different visuals to help explain the answer to this question, but there are still those who are having trouble.The question posed is “… Unfortunately, your friend sent the message at one-half the bit rate you agreed upon, … What message did you receive instead?” [instead of ABAB] We used 2 sec and 1 sec (as half-bitrate) for ease of illustration - I thought! But my students are getting hung up on the “timer” - where A is sent, they see as the 1st second, so read B (because it’s the , first, then B again, then 2 more B’s since the wire is holding that state as the last one sent. Please help me with a good explanation as to why both send and read begin with A
This is a response Baker gave last year to this problem: So a source of confusion here is probably the phrase “bits per second”. Up to this point in the course students are probably thinking of how many seconds it takes to send a bit. For example, if I send 1 bit every 2 seconds, that’s 0.5 bits-per-second. This is confusing. So, as the writer of this question, I agree it should be re-worded to better fit students’ experience at this point in the course. If the problem were reworded this way it might be clearer.
“…Unfortunately your friend sent one bit every 2 seconds, but you read the wire once every second. What message did you receive?”
Then it might be easier to see the timeline events:
1:A--------B--------A--------B
2:^—^---^----^—
Does that make it more clear?
He rewrote the question on code studio but not on the lesson plan.
I hope this helps
Karen
1 Like
FIxed the lesson plan so it matches code studio now.
Thanks, Karen. I had seen Baker’s explanation which was very helpful for setting up the problem. However, my students were stumbling on an issue with the timing; we used 2 seconds and 1 second. They started counting 2 seconds at the transmission of A, not reading A - but beginning their 2 seconds so that the first bit read was B. I know it’s confusing to explain. I will revisit stating one assumption, that transmission begins with the setting and reading of the first bit. I hope this gets everyone on the same page. Simple concept being “overthought” I think. Thanks again to you and Baker.
At the risk of overthinking the overthink…perhaps think about it this way:
Imagine that you are turning a flashlight on for 2 seconds, and then off for 2 seconds, on for 2, off for 2, repeatedly in a dark room. And your partner is standing with her eyes closed, but blinks them open every 1 second, long enough to ascertain if there is light or there isn’t.
This shows how the timing works for this scenario. ^ means the eyes are blinking open at that moment.
REAL TIME: 0----1----2----3----4----5----6----7----8
FLASHLIGHT: ON------->OFF------>ON------->OFF------>ON
EYES: ^----^----^----^----^----^----^----^----^
This results in the reader seeing a pattern of ON-ON-OFF-OFF-ON-ON-OFF-OFF…
This is basically how the simulator works. When you set the wire to A or B is it like turning a flashlight on or off - it stays in that state until someone sets the wire to something else. When you read the wire is it like blinking your eyes open in a dark room - you see the state of things but only for an instant.
Perhaps there is confusion around needing to synchronize the clocks - i.e. attempting to have the setter and reader do things at the exact same tick of the clock, the exact same moment. It turns out you don’t need to, and shouldn’t!. As the diagram below shows, as long as the person starts their once-per-second blinking at ANY POINT within the first second they will see the same pattern.
REAL TIME: 0----1----2----3----4----5----6----7----8
FLASHLIGHT: ON------->OFF------>ON------->OFF------>ON
No sync: ----^----^----^----^----^----^----^----^----^
This is similarly true when the partners agree on and execute the same protocol. If we agree to set or read the wire every 2 seconds our clocks don’t need to be synchronized either, because if I’m reading once every 2 seconds, that read will occur BETWEEN the moments when you set the wire, so I’ll easily read what you set it to.
In fact, somewhat counterintuitively, if our clocks are perfectly synchronized it’s much more likely the reader will read the wrong thing because the (human) setter and reader are trying to do something at the exact same moment in time. Think about the flash light scenario: you try to turn the flashlight on or off at the exact same moment your partner is blinking their eyes. The odds are good that at some point your partner will blink her eyes open the split second before the flashlight turns on. It’s much more reliable, actually, if the clocks are perfectly out of sync because it ensures the state that needs be read is in place well ahead of the potential read, and it will remain up for some time before it changes.
Baker
CSP Team
1 Like
Thanks so much for the quick reply and excellent explanation. I will share with my students and I’m confident it will clear things up for them. Have a great day!
There is a similar question on the Activity Guide Coordination and Binary Messages:
A binary message consisting of 4 bits was sent to you by a friend. The message was supposed to be ABAB. Unfortunately, your friend sent the message at one-half the bit rate you agreed upon, while you read the message at the original rate. What message did you receive instead?
Is it the same answer as the one you are referring to?
sorry for the delay in my response, In this case, the answer would be BBBB.
If the agreed that the bit rate for reading the wire was every 2 secs but the message was sent every 1 second, this is what it would look like:
0 2 4 6 8
. . . . .
A B A B A B A B
So the receiver would read BBBB.
@karenma Shouldn’t it be AABB?
Great catch @bhatnagars. The sender would leave the wire set on B after sending the 4 bits while the receiver was still reading the wire 2 more times.