MCU scan sequence does not match documented 31-elevation / ±45° steering design

[wordisworld]

Problem

The current MCU scan scheduler in runRadarPulseSequence() seems inconsistent with the documented radar scan design.

Documentation and FPGA comments describe:

• 31 elevation positions per azimuth
• electronic steering of about ±45°

But the MCU currently performs:

• 15 outer beam positions
• 3 dwells per outer position
• total: 45 electronic dwells per azimuth step

Current implementation

In 9_Firmware/9_1_Microcontroller/9_1_3_C_Cpp_Code/main.cpp, each beam_pos does:

1. load matrix1[beam_pos]
2. run chirp sequence
3. load vector_0
4. run chirp sequence
5. load matrix2[beam_pos]
6. run chirp sequence

So the actual sequence is:

• matrix1 -> vector_0 -> matrix2
• repeated 15 times

This means broadside (vector_0) is repeated 15 times in one azimuth dwell.

Why this looks wrong

• The scheduler executes 45 dwells, not a direct 31-beam sweep.
• 0° / broadside is overused.
• The grouping is not symmetric +A, 0, -A.

From phase_differences[], the sequence looks like:

• +160, 0, -10.667
• +80, 0, -11.429
• +53.333, 0, -12.308
• ...
• +10.667, 0, -160

So this does not look like a clean left-center-right beam scan.

Additional concern

The same file includes:

// steering angle (rad)= arcsin(phase_dif/Pi)

If that relationship is assumed, then ±45° would correspond to about ±127.3° phase increment, not ±160°.

So the current beam table may also be inconsistent with the documented ±45° steering target.

If I got this wrong, or if I am misunderstanding the intended behavior, please let me know.

[NawfalMotii79]

@wordisworld check the following code

void ADAR1000Manager::adarSetRxPhase(uint8_t deviceIndex, uint8_t channel, uint8_t phase, uint8_t broadcast) {
    uint8_t i_val = VM_I[phase % 128];
    uint8_t q_val = VM_Q[phase % 128];

    uint32_t mem_addr_i = REG_CH1_RX_PHS_I + (channel & 0x03) * 2;
    uint32_t mem_addr_q = REG_CH1_RX_PHS_Q + (channel & 0x03) * 2;

    adarWrite(deviceIndex, mem_addr_i, i_val, broadcast);
    adarWrite(deviceIndex, mem_addr_q, q_val, broadcast);
    adarWrite(deviceIndex, REG_LOAD_WORKING, 0x1, broadcast);
}

[JJassonn69]

@wordisworld looking into this aswell, it could be a genuine scheduler/design drift issue.

[NawfalMotii79]

@wordisworld @JJassonn69 ....is it possible at this stage to add triggered sector interrogation capability?

[NawfalMotii79]

changes.cpp

[JJassonn69]

@NawfalMotii79 it should be possible since all the parts of the triggering, targeting and mode selection are configurable without much change to the architecture itself. We would need to decide how exactly we want it implemented.

[NawfalMotii79]

@JJassonn69 any suggestion?...What about adding a camera (OpenMV) that scans the sky and once the targets detected, the RADAR focuses its scans on determined sectors?

[JJassonn69]

@JJassonn69 any suggestion?...What about adding a camera (OpenMV) that scans the sky and once the targets detected, the RADAR focuses its scans on determined sectors?

for extended range antenna that wont work great, maybe for prototyping with complete hardware we can make the doppler map interactive so the user can focus on a specific target. WDYT?

[wordisworld]

@NawfalMotii79 @JJassonn69

1.Even if the new scan uses 31 elevation beams over ±45°, that still may not be a good fit for a low-altitude drone radar in practice.

For example, if a drone is flying at about 200 m altitude,
then at 200 m horizontal distance the elevation angle is already about 45°.
In real radar applications, the useful elevation coverage is often something like -5° to 40° or maybe up to 60°,
and most drone targets are concentrated in the low-altitude region.

Also, as a phased-array beam moves farther away from boresight, the beam gets wider.
Because of that, high elevation angles may not need as many beam positions,
while low elevation angles may actually need more coverage,
especially when ground multipath is a concern.

So a symmetric ±45° / 31-beam design may not be the most practical scan strategy.
It can waste beam resources at high elevation, while still not giving enough coverage density at low elevation where detection is harder and multipath is more important.

2. I do not think using a camera as the search sensor is the best direction here.
   My view is :
   let the radar do the wide-area search first,
   and then use the optical system to follow up once the radar has already detected and localized a target.
   In other words, radar should cue the camera, not the camera cue the radar.
   The camera has a limited field of view, is sensitive to lighting and weather,
   and in many cases it is not the right sensor to do the first-stage search.

or Maybe we could try designing a TAS mode for radar , not only tws.

3. in my view, the question is not only whether the Doppler map should be interactive,
   but whether the underlying radar design is strong enough in the first place.
   If the scan strategy, low-elevation coverage, multipath mitigation, and clutter suppression are not well designed,
   then making the Doppler map interactive may help the operator a bit, but it will not fundamentally solve the detection problem.

[NawfalMotii79]

@wordisworld @JJassonn69 ...After discussing with PCBWay Marketing manager, we decided that they will produce for free the PCB and PCBA in an iterative way (maybe 3 to 4 versions)….I need you to decide whether we produce rapidly the RADAR_V6 or we try to get some review about the hardware first and we include the suggested enhancements (OpenMV camera, LAN, synchronization of multiple boards).
Please note that the main board still needs some refinements (Length match of RF traces, some via fencing, routing the USB3 lines, Ground pouring, silk screen…).
Responding to @wordisworld about the +/- 45°, this is not a fixed configuration, however for my defense, you need to know that we would be using a tangled platform over the tripod, hence the use of an IMU.

[JJassonn69]

@NawfalMotii79 I think iterative approach is better for diagnosing any issues we might face when testing the hardware. Once we verify that we have a solid working foundation with the hardware we can add features.

[bahari]

Finish the hardware design FIRST is the most important things in every projects IMPLEMENTATION. The firmware and software is the continuous development that can be change all away during products testing. Confirm the crucial parts first, which is the hardware design especially PCB and components operation validity. The digitizer and RF front end hardware for me is the critical parts.

[NawfalMotii79]

@bahari The Hardware design is complete, but you need to know that for every complex project an iterative process is needed. For example, the Power Amplifier board uses a GaN chip (QPA2962) that was easily procurable in the past, but when I tried to order it, I faced the crude reality of the shortage. So during the next 10 days, I’ll be designing multiple Power Amplifier Boards so the users will have multiple options to choose from.
Also, what I recommend to the hackers that want to build the system by their own, to wait until I receive the PCBs .

[bahari]

Very thanks @NawfalMotii79 for your efforts in order to make this project success.Regarding ADAR1000, is it easy to get it?

[NawfalMotii79]

@bahari All the components are easy to procure