Zoltan Miskolci

About
  • First commit 04 December 2025
  • Latest commit 10 August 2026
Last Week All Time
Commits: 28 433

Reviews

49 active reviews

Counts may include data that you cannot access.

Line History

Line history chart not available

Line history chart not available

 

Commit Activity

Commits By Day In Week
52 week commits volume
Commits By Day In Week
Commits by day
Commits By Day In Week
Commits by hour
Commits By Hour In Day
Commit calendar
 

Committer Mappings

Zoltan Miskolci is mapped to 4 committers over 3 repositories
Username zmiskolci is mapped to:
Today
2 hrs ago

Zoltan Miskolci

I think that's what is usually shown, the first 7 char, but in this case it might have been a typo

I think that's what is usually shown, the first 7 char, but in this case it might have been a typo

Friday 07 Aug
3:49 pm

Zoltan Miskolci

No need, in a different CR I have a module that pulls the Alarm ID, Reject Reason and Msg Ids directly from the FW. After that's merged, this file won't be needed any more manual update. For more ...

No need, in a different CR I have a module that pulls the Alarm ID, Reject Reason and Msg Ids directly from the FW. After that's merged, this file won't be needed any more manual update.

For more information check LDT-5205 CR, file: utils\ enum_updater.py

Thursday 06 Aug
2:38 pm

Zoltan Miskolci

Wrong MsgID Update the entity name too

Wrong MsgID
Update the entity name too

2:38 pm

Zoltan Miskolci

Wrong MsgID Update the entity name too

Wrong MsgID
Update the entity name too

2:37 pm

Zoltan Miskolci

Update header

Update header

2:36 pm

Zoltan Miskolci

Update header

Update header

2:36 pm

Zoltan Miskolci

.name Use the name as key, to match the above suggested changes

.name

Use the name as key, to match the above suggested changes

2:35 pm

Zoltan Miskolci

.name Use the name instead of the full enum for key

.name
Use the name instead of the full enum for key

2:34 pm

Zoltan Miskolci

import from msg_ids, because the enum located there not in msg_defs

import from msg_ids, because the enum located there not in msg_defs

2:34 pm

Zoltan Miskolci

Update

Update

2:33 pm

Zoltan Miskolci

Align the values please

Align the values please

2:32 pm

Zoltan Miskolci

Conflicting with existing ones

Conflicting with existing ones

Wednesday 05 Aug
3:02 pm

Zoltan Miskolci

Wednesday 29 Jul
5:03 pm

Zoltan Miskolci

3:36 pm

Zoltan Miskolci

3:33 pm

Zoltan Miskolci

Fixed in all 3 file

Fixed in all 3 file

3:12 pm

Zoltan Miskolci

Please add a NUM_OF_VALVE_STATES = 4 member too

Please add a NUM_OF_VALVE_STATES = 4 member too

3:12 pm

Zoltan Miskolci

Update this list too

Update this list too

3:11 pm

Zoltan Miskolci

Remove from here too

Remove from here too

Monday 20 Jul
4:56 pm

Zoltan Miskolci

Monday 13 Jul
11:51 am

Zoltan Miskolci

Thursday 09 Jul
9:00 am

Zoltan Miskolci

Wednesday 08 Jul
9:00 am

Zoltan Miskolci

Tuesday 07 Jul
3:23 pm

Zoltan Miskolci

Thursday 02 Jul
9:54 am

Zoltan Miskolci

Wednesday 01 Jul
3:03 pm

Zoltan Miskolci

3:02 pm

Zoltan Miskolci

The approach of what this code does and the conversion module are similar in function but a differ on maintenance and flexibility. 1. The conversion module's bytearray to value methods work, but th...

The approach of what this code does and the conversion module are similar in function but a differ on maintenance and flexibility.
1. The conversion module's bytearray to value methods work, but they require manual logistic around the indexing. It's the user's responsibility to handle where the reading starts and you need to code the handler for that (previous approach with MsgFieldPositions), It's inflating the method. I worked hard to remove the need for indexing where the value starts. Instead of the previous struct.unpack approach, where you needed to maintain the type, you will be needing to maintain the conversion methods that are being called, so it would be the same as before, you still need to mind the indexing, which was the main reason of changing from this approach.

2. In the current approach, you declare the type and pass it to a processor that dynamically handling the unpack type (based on the set datatype) and the indexing for that. This works much better and easier to maintain, as you can just insert a new value when it's added to the FW, and don't need to adjust all your indexes for the reading.

Example #1, changing build type from U16 to U08:

  • with the conversion approach, you need to change the function used, and update the starting index for all the following methods.
  • with the current approach you change the Datatype.U16 to Datatype.U08 and that's all you need to do.


Example #2: adding a new variable fpga_micro after fpga_minor, with U08 type:

  • with the conversion approach, you add the bytearray_to_byte, update the indexes for all the following reads.
  • with the current approach you insert an element after the fpga_minor with a value ('fpga_micro', Datatype.U08), and nothing more needed
2:40 pm

Zoltan Miskolci

Add uncompensated conductivity to the init too

Add uncompensated conductivity to the init too

2:40 pm

Zoltan Miskolci

Add uncompensated conductivity to the init too

Add uncompensated conductivity to the init too

2:25 pm

Zoltan Miskolci