Hi, I just wanted to highlight that in the latest version of Carto there is a fairly significant change in the export format. We have added a feature branch to opened-core called newfilestructure which should handle this change. Hope that helps anyone who is struggling with this issue!
I attempted to work with data exported from CARTO version 7.5.1.327 using the new scripts in newfilestructure. However, an error message was displayed:
Can anyone help me?
Thanks,
Valentina
Hi Valentina, welcome to OpenEP! I would be very happy to help you with this problem. Often, this error happens because of electrode naming. If you would like we could have a look together? Please could you check my availability here Meeting Request - 45 minutes — Fantastical Openings
We’re having the same issue! Will ship the data over asap if you are happy to help 
Great, sounds good, I don’t think this will be hard to fix
Thank you, Steven! I am having difficulty finding a moment to meet with you next week. Could you please provide me with some tips? If you would like, I can give you my email.
I’m using Matlab R2020b, could be a problem?
I found that the problem is in this code line (importcarto_mem line 465)
electrodeNames_uni{iPoint,2} = incrementUnipoleName(pointTree.ECG.ATTRIBUTE.UnipolarMappingChannel);
that returns ‘CS11’ but there is no an electrode with this name in my files, so kMap_uni has only one element.
Hi, Martin has also had this problem - I’m writing a patch for it just now. it will be interesting to see if it fixes both of your problems.
@valehwg can I ask what you are mapping - were you mapping using the Deca connector to e…g map the LV/RV?
Hi, we are mapping the RV with a CS connector (last patients) and this is the list of our ecgNames:
‘M1(1)’
‘M2(2)’
‘M3(3)’
‘M4(4)’
‘CS1(11)’
‘CS2(12)’
‘CS3(13)’
‘CS4(14)’
‘CS5(15)’
‘CS6(16)’
‘CS7(17)’
‘CS8(18)’
‘CS9(19)’
‘CS10(20)’
‘V1(22)’
‘V2(23)’
‘V3(24)’
‘V4(25)’
‘V5(26)’
‘V6(27)’
‘M1-M2(92)’
‘M3-M4(94)’
‘CS1-CS2(101)’
‘CS2-CS3(102)’
‘CS3-CS4(103)’
‘CS4-CS5(104)’
‘CS5-CS6(105)’
‘CS6-CS7(106)’
‘CS7-CS8(107)’
‘CS8-CS9(108)’
‘CS9-CS10(109)’
‘I(110)’
‘II(111)’
‘III(112)’
‘aVL(171)’
‘aVR(172)’
‘aVF(173)’
Thanks, @valehwg that’s the code modified slightly so that I think it can import your data.
The problem happened since (until now) we assumed that the second unipole channel was one greater than the first. So, for example, if the first unipolar channel was 20A-1,2, then the first unipolar channel has always until now been specified by the system as 20A-1. We then increment the 1 to 2 and we assume in OpenEP that the second unipolar channel is 20A-2.
However, for the particular point in question in @martin.bishop’s dataset the Unipole channel was specified as CS10. By our logic, the second unipolar channel should be CS11, which of course does not exist.
<ECG FileName="17-LV S1_ECG_Export_9504814.txt" UnipolarMappingChannel="CS10" BipolarMappingChannel="CS9-CS10" ReferenceChannel="V5" /><ECG FileName="17-LV S1_ECG_Export_9504814.txt" UnipolarMappingChannel="CS10" BipolarMappingChannel="CS9-CS10" ReferenceChannel="V5" />
We have implemented a quick check to see if the assumed second unipolar does not exist. If it does not, we then go back to the original unipole and decrement by 1. So for the example given, we correctly end up with CS10 as the first unipole and CS9 as the second unipole.
One problem I foresee with this is what happens if for example, a channel is specified as CS8,9 with a unipole of CS9 - do we then end up with an erroneous unipole of CS10, rather than CS8, because CS10 exists.
I think we need to do a further check to make sure that the assumed unipole somehow exists in the electrode naming of the bipole.
Modified code is available here: GitHub - openep/openep-core at feature/newfilestructure
I would be good to hear if it helps with your issue or not
OK, sorry this was a bit harder than thought.
I’ve pushed a new update which deals with different styles of bipolar/unipolar electrode naming.
Grateful if you can both test