crimac-wp4-machine-learning / crimac-raw-to-svf-tsf Goto Github PK

For any other json dataset than the original (pyEcholabEK80data.json) I get a

IndexError: index 1024 is out of bounds for axis 0 with size 1024

error when running main.py.

This happens in line 319 Y_pc_t_m = _Y_pc_t_m[idx] (EK80CalculationPaper.py)

The idx in

@staticmethod
def calcDFTforTS(y_pc_t_n, y_mf_auto_red_n, n_f_points, f0, f1, f_s_dec):

idx seems to "duplicate"?:

...1004 1005 1005 1006 1007 1007 1008 1009 1009 1010 1011 1011 1012 1013
1013 1014 1015 1015 1016 1017 1017 1018 1019 1019 1020 1021 1021 1022
1022 1023 1024 1024 1 2 2 3 4 4 5 6 6 7
8 8 9 10 10 11 12 12 13 14 14 15 16 16
17 18 18 19 19 20 21 21 22 23 23 24 25 25...

When trying to calculate the angles from y_pc_nu I get an error on np.atan2. Also the code coverts to degrees, but I think the notation in the paper suggests radians? Also, the function returns y_alon and y_athw, which is undefined in the paper. Perhaps update the paper? The name of the function is also erroneous since the function does not return the electrical angles (Eq 13 and 14), but partially calculates the physical angles by calling the arctan2 but not the correction factor and the arcsin/arccos step in the function (Eq15&16 in the paper).

In [144]: y_theta_n, y_phi_n = ekcalc.calcElectricalAngles(y_pc_nu)

AttributeError Traceback (most recent call last)
in ()
----> 1 y_theta_n, y_phi_n = ekcalc.calcElectricalAngles(y_pc_nu)

d:\repos\Github\CRIMAC-Raw-To-Svf-TSf\Core\EK80Calculation.py in calcElectricalAngles(self, y_pc)
306 y_pc_port = 0.5 * (y_pc[1, :] + y_pc[2, :])
307
--> 308 y_alon = np.atan2(np.real(y_pc_fore), np.imag(np.conj(y_pc_aft))) * 180 / np.pi
309 y_athw = np.atan2(np.real(y_pc_star), np.imag(np.conj(y_pc_port))) * 180 / np.pi
310

AttributeError: module 'numpy' has no attribute 'atan2'

I started reviewing the paper and comparing to the code.

In the example ekcalc = EK80Calculation('./data/pyEcholabEK80data.json') the result has field ekcalc.f_s. In the code the f_s is not consistently used. Some places uses fs. Should we not either use Tex formatting throughout or not?

Is the ekcalc.y_rx_org the decimated data stored in the raw files? If this comes from the raw files is this not y_rx(n,u)? The y_rx_org seem to be complex (from the filter bank) and passed directly to the pulse compression function, and not the data prior to the filter bank, as defined in the paper. If this is correct we should use y_rx_nu instead of y_rx_org. for consistency we should also use y_rx_org_nu instead of y_rx_org.

The json file has this field: "Raw file": "C:/Users/a32685/Documents/Projects/2020_CRIMAC/CRIMACHackEx/cal-babak-D20201120-T080856.raw",. should we remove that? The json files also has names associated with LSSS and pyEcholab. Do we not want to make this independent of these packages/software solutions?

I think we should use y_pc_nu instead of y_pc_u for consistency when referring to $y_pc(n,u)$.

Again, for consistency y_mf_auto -> y_mf_auto_n.