ESP32 SPI with AS5048A Encoder: Troubleshooting Connection and Code Issues

I recently bought some AS5048A encoders, communicating with the master over SPI. I assembled a connection like this:

.

and uploaded the example I found:
.

Unfortunately after uploading the code to the ESP32 dev Module, I get the same zeros whether I apply the magnet or not. When I get home with this the first thing I'll check is that I have an SCL signal on the oscilloscope and that I have a low state on pin 27 every second, but I'd also like to ask if maybe something is wrong with the code or pinology?
.

I also tried from HSPI pins before and there was no difference either. At the moment I have shortened the code from the link just to handle HSPI.
.
However, I don't really understand how it works.
When I was using I2C I knew that first you have to establish a connection, give the address, register address, how many bytes etc....
With SPI I know that when picking up data from the slave, the CS pin is supposed to be in the low state, SCL is the clock, and MoSI and MISO are something like RX TX.

In the loop I have a call to the communication function:
.
Could you please explain what is contained in beginTransaction, and what is behind the transfer(stuff) command;

https://www.mouser.com/datasheet/2/588/AS5048_DS000298_3-00-522570.pdf

Added after 11 [minutes]:

I'm looking for information on how to receive two bytes of encoder position information

Added after 16 [minutes]:


.
Above I have the position read address, but how do I use this in code to read the contents of the register at address 0x3FFE?

I was about to give up on it. I tried it on UNO and MEGA and got zero readings. Finally, using the link:
https://forum.arduino.cc/index.php?topic=155238.0
I noticed that MOSI is permanently connected to 3V3 and suddenly everything started to work. Below I am uploading the ready-to-read AS5048A on ESP32
.
Thanks for the links to the SPI, a lot of news it gave me

Of course I would like to be able to program it, or a more apt word is to be able to. I would be most interested in setting the zero position. I understand the Transfer function as sending the appropriate byte, and in response the function returns a response in place of that byte.
I don't understand why this response comes after sending two bytes with a value of 0? I know the value is 14-bit, so we are not looking at the two oldest bits, but why are we sending 0?
Is it not really a 0, just the first byte of the array?
The register address I'd like to read the position from is 0x3FFE. I thought it would work on the principle that I split this value into two bytes, add a 1 to the older one in the 15th bit to let it know it's a read, and send that to the encoder. I've also tried Transfer(Val16), but also nothing.

I now understand everything. Tracing made everything clear to me. That is, we send the appropriate command + a 1 in front and then send 0 as a read. I had sent the former before, but didn't know that you then have to send a 0 to get the response. I'm ordering 6-wire shielded cables and when they arrive I'll try to fit these encoders to my robot instead of the AS5600. I hope that if they are connected directly to the ESP32 there will be no interference.
Thank you.

the one from the furthest axle 180cm

Today I soldered the encoders to the shielded cable
.

.
and I temporarily connected 2 of the 5 encoders on a test basis in a "3 Wire Mode (read only)" connection.
.
Tomorrow or the day after tomorrow (if I don't have trips at work), I will try to assemble the encoders on the individual axes and see how it works.
I'm just asking for input on whether this kind of reading is optimal?
.

.

Today I quietly connected everything, separated the 5V control voltage from the motors supply voltage. After switching on the control and moving the axes freely, 0 reading errors, but unfortunately after switching on the power supply to the motors automatically erroneous readings.
Well, I don't know where the interference comes from anymore. The same encoders are used in professional applications by Boston Dynamisc who use them in their motors doing such wonders:
https://www.youtube.com/watch?v=NR32ULxbjYc
Perhaps my problem is that the encoders and magnets are not in a metal box forming a Faraday shield and the magnetic field of the motors affects their reading, or perhaps the ESP32 itself is too susceptible to interference.
Overall communication with AS048A resolved, but it's a shame not with positive results .

Well, an oscilloscope indeed! Unfortunately it is of the lower regiment, but it shows something:

.
Above, the MISO signal at intervals with the engines switched off


and here approximately. Unfortunately my oscilloscope does not give a full view of the whole frame
Below please see what the signal looks like when the power supply is switched on:
.
and approximately:
.
I am also sending a short video where it is shown what it looks like before and after the engines are switched on.

https://www.youtube.com/watch?v=qlD52KkkEK8&feature=youtu.be if the video does not fire
I have in the program that if the reading is 300 position units higher or lower than the previous reading, it is supposed to fire an error with an alarm. Sreial.print here has no effect on anything. I tried controlling the robot without serial and also position errors unfortunately.
I'm having a temporary problem flipping pictures from my phone, but on the picture with the previous I2C multiplexer it looked similar:
.
.
Now there is a board where the shielded encoder wires are plugged in and connecting all of them:
+Vcc
GND to which the shield is connected
MISO
SCK
these 4 above wires at the output of the board go about 10cm by wires to the ESP32. Each CS wire also goes loosely to the ESP32. I won't be able to do any more today as I'm leaving the house, but tomorrow I'd like to try hooking up the encoder board to an Arduino Mega with a read only program uploaded and see if it's the same. Thanks for the hint with checking the signal on the oscilloscope

The motor cables should also be shielded, a subject well known from 3D printers, for example, where the proximity of motor cables and e.g. tap wires caused the stop to be switched on due to the interference generated.


Regards

.
This is how it looks when it comes to the encoder wires
Regarding the motor cables, I somewhat regret that I did not use shielded cables right away. If it would have helped then I will definitely replace them with shielded ones.
I'm about to get round to switching everything over to reading the position from the Arduino Mega, just out of curiosity as to whether changing the microcontroller here will have any effect on the correctness of the reading.

.
I quickly assembled something like the one above and it's the same, admittedly now only misreading from one encoder (I'll ditch it later), but there it is.

.


SCK signal seems ok, CS signals are 100% perfect. Regarding the MISO, I wonder why the signal doesn't drop instantly to zero after readings, but often goes down slowly to ground potential.
I have the MOSI pin on the Arduino side unconnected

Added after 2 [minutes]: .

I see, I will also try disconnecting the screen from the encoder side

Added after 4 [hours] 32 [minutes]:

Hmmm... All I did was isolate the screen from ground at each encoder according to the guidelines and to my surprise (as I've always been told the screen should be wherever it goes) complete lack of erroneous readings. I typed in the code to count the erroneous readings and display the status of this counter every second and for over an hour the counter status was 0, also great, thank you for such a guideline. For now I have this result for the Arduino Mega, tomorrow I'll try to get the wires in order in conjunction with the ESP32 and hopefully eventually get the robot "driving" .
But I'm puzzled as to why isolating the ground from the shield at the encoder resulted in better interference cancellation?