Couple suggestions

[plurnt]

This is really cool :)

A couple things noted,

I saw that someone posted the ACK is random or just a timestamp; the iclickers do have some sort of 2way communication since there is the instructor remote which has additional features as well as the student remotes having multiple question types (sending 1-8 digit numerical/1-16 character alphanumeric answers, the roll call feature, and the refresh button), the student remote has to somehow know to change modes to another question type. so this information is probably encoded in the ack? i think it's likely the ACK, like the multiple choice answer packets, is just the remote ID encoded with some true/false values representing this.

there is also an optional 8-character welcome message on the iclicker 2s

this also leaves the packet structure for other answer types left.

suggestions for other features,

one where it'll continuously monitor the submitted answers and submit/keep updating your own answers to whatever the most popular choice is until the polling is closed (i guess a poll open/closed notice should also be encoded in the ACK?)

and one where we try to sniff for the instructor remote ID so we can start submitting start/stop poll commands under that. iirc the instructor remotes for iclicker 2 are distinct from student remotes so their packets sent should be slightly different? that would involve also figuring out packet structure for instructor remotes.

[wizard97]

Hi,

We actually tried the random ack, and the remote did not accept it, so there is definitively some encoding going on. Also, the ack's that we have captured change, there is no clear pattern. All of the reverse engineering has focused on the basic multiple choice answering functionality. We really have no idea how the additional functionality works.

The api actually already supports what you are asking, just nobody has gotten around to writing a simple Arduino sketch to do it. It would be pretty trivial, keep sending pings to the base station until you get an ack (I don't believe the base station replies to pings until polling is open). Once this done, capture everyone else's answers (we already have a program that does this), and submit your answer based on the most popular choice. If you feel like doing this, would definitely accept a pull request.

As for instructors remotes, I believe they in fact behave the same way as normal remotes. In the iClicker software you have to input the instructor remote id, then I believe each of the answer choices maps to a certain functionality. We really have no way of testing it, because we don't have access to instructor remotes.

[wizard97]

If your curious, here is some captured data for the 7 byte ack:
https://github.com/wizard97/iSkipper/blob/master/data/base_response/1.txt

[Th3OnlyN00b]

Gonna catapult off of this: I have recently come into possession of an instructor remote and an iClicker2 base. I have also met up with @charlescao460 and we will be working on decoding the ack soon. Currently the xnorer is not working but we are looking into that. At the very least we will be able to check if the signals the instructor remote sends are the same or not.

[orangeturtle739]

Great, let us know if you decode the ack! That is the only thing we never got. Also, we are pretty sure the instructor remote is the same as a normal iClicker. If you download the iClicker basestation software, you see that you just need to enter the ID of the instructor remote; we suspect it just listens for submissions from that remote and handles them differently.

[wizard97]

Even if you can't figure it out yourself, it would be really cool if you could capture a bunch of responses (along with the corresponding answer submissions), so we can try and reverse engineer it with massive amounts of data...

Let us know as you make progress!

[Th3OnlyN00b]

Certainly. We will work on writing a new script to capture the data cuz the library seems to be a lil broken for now

…

On Sat, Feb 16, 2019, 12:03 AM Aaron Wisner ***@***.***> wrote: Even if you can't figure it out yourself, it would be really cool if you could capture a bunch of responses (along with the corresponding answer submissions), so we can try and reverse engineer it with massive amounts of data! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF-G3QBvKZyeRz61LCSniadFPvchvTRBks5vN5ESgaJpZM4Pry5r> .

[wizard97]

xnorer has been broken after a recent merge from dev. I think the best strategy is just capture a bunch of data than can easily be analyzed locally with python.

[Th3OnlyN00b]

I agree. I'm rather curious to see how this analysis happens though as I've never done anything like that before. All that said we will def collect data. How much do you think is required?

…

On Sat, Feb 16, 2019, 12:39 AM Aaron Wisner ***@***.***> wrote: xnorer has been broken after a recent merge from dev. I think the best strategy is just capture a bunch of data than can easily be analyzed locally with python. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF-G3d4b2HH-WzRRfJKOcHtvKTtbn7rAks5vN5l_gaJpZM4Pry5r> .

[wizard97]

First we need to see if the ack is deterministic (given the same remote, with the same answer, do you always get the same 7-byte ack back?), our initial findings was that they were not. I think that is the main thing that is going to determine how much data is needed to reverse engineer it.

[ammaraskar]

#11 and https://blog.ammaraskar.com/iclicker-reverse-engineering/ might interest the original poster and @Th3OnlyN00b. I did see code relating to sequenced questions/alphanumeric modes but I didn't go too in depth into it.