Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Red Hex Values (0A, 75, 89, CC) #54

Open
AzarathAzzy opened this issue Aug 9, 2024 · 1 comment
Open

Red Hex Values (0A, 75, 89, CC) #54

AzarathAzzy opened this issue Aug 9, 2024 · 1 comment

Comments

@AzarathAzzy
Copy link

AzarathAzzy commented Aug 9, 2024

As requested by the "status" section of the readme, I'm opening an issue regarding red hex values when connected to a network.

dysenterypng

In this issue I will be referring to a webpage / website. I am referencing the "DJ Link Ecosystem Analysis" Webpage which
has a section in it detailing the purpose of each value I'm talking about. The details of the bytes can be found in the "Detailed Device Status" Section of the webpage

Values 0A, 75, 89, CC display in red after monitoring a ProDJ Link network with 2x CDJ-3000s and 1x DJM 900NXS2
No tracks were loaded onto any of the players, but a USB Storage device was inserted and detected by both CDJs

Byte 0A - as stated on Ecosystem Analysis webpage, the value "0A" is expected in this position, despite the value displaying as red.

Byte 75 - Value returns "00" Despite there being a media device (USB) Connected to both CDJs over the network, which is contrary to what the website states, saying that L (Value 75) will return "01" With any USB in the network

Byte 89 - Refers to variable "F" which returns "80" in hex (10000000 in binary). This is unexpected as bit 2 is expected to return a value of "1" as stated on the website.

Byte CC - Refers to variable "Nx", which returns 0F for Nexus players, 1F for the XDJ-XZ and CDJ-3000, and 05 for older players. Byte CC Returns the hex value "1F" Which is expected for CDJ-3000s, despite the red value.

--

To Reproduce:
This was the status the CDJs were in after being turned on and left untouched. No other devices were connected. No network devices were connected other than a laptop running dysentery in a VM.

P_20240809_075347

Note, the displays are dimmed not due to a user setting but due to standby mode after being left untouched after a period of time
Both CDJs are on firmware version 3.13. All CDJs and the DJM were linked through a switch

--

After some testing:

After loading a track on player 3 from a USB on player 2 (Via link) Byte 89 on player 3 returns "84" which shows up in green which gives the binary value "10000100" which is expected. Bit 2 returns 1, which is expected in contrast to the previous result, returning 0. All other bits in this value are expected. (beat sync, master, playing, on-air, BPM sync are all off)
loading a track on player 2 from the USB in player 2 yields the same results

After ejecting the USB that the CDJs had loaded tracks from, byte 89 returns "88" on player 3 and "80" on player 2
Player 2's "80" being the same as before
Player 3's "88" (10001000) (bit 3 being 1 is expected as the mixer was left with the fader up) seems to correlate with my thinking:
Speculation: Maybe bit 2 in value 89 returns 0 when a track isn't loaded?

After ejecting the USB on player 2, byte 75 on player 2 returns "00" which is no longer showing in red, but does not follow in line with what the website states "appears to have the value 01 whenever USB, SD, or CD media is present in any player on the network, whether or not the Link option is chosen in the other players, and 00 otherwise." This seems not to be the case, as there is still a USB linked over the network on player 3, but the value I'm seeing on player 2 is "00"
Speculation: I'm unsure of what this byte is actually supposed to return and the purpose of it. it seems there's some strange behaviour happening here?

Further testing to be reported

@brunchboy
Copy link
Member

Thank you for this! Yes, I agree that those bytes are pretty confusing. Unless you are able to come up with some concrete useful interpretation in your continued testing I think our best bet is just to downgrade our expectations and document that we don’t know what they represent. Beat Link doesn’t rely on them for anything.

By the way, since I originally set up this documentation site, I have grown a community on Zulip, which can offer a more lively and informal discussion of exploration like this if you are interested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants