####### 
 ##  ##  
    ##   
   ##    
  ##  ## 
 ####### 
         

         
         
 ######  
    ##   
   ##    
  ##     
 ######  
         

         
 ##      
 ##      
 ## ##   
 ####    
 ## ##   
 ##  ##  
         

 _____ 
(  _  )
| (_) |
|  _  |
| | | |
(_) (_)
       
       

         
|\     /|
| )   ( |
| (___) |
|  ___  |
| (   ) |
| )   ( |
|/     \|
         

IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now.


Visit Preferences to set your user name
Summary of change:
Subpage of MembersPage/Kamuto The aim page: BroadcastDatastreamAim I would like to know what is difference in AIM stream when it's on first serial port and when it's on second serial on vems ecu, is there any difference in byte order or other stuff. * Answered on the relevant page BroadcastDatastreamAim ** no difference in byte-order, the exact same data is sent ** some non-smart decoders, instead of using the A3 as reference position (A3 is always present in every 5 byte AIM packet, always same position, although the 2nd byte, not the 1st... stupid but respected) * the time-gaps between the 5byte packets (is the difference) are NOT necessary for decoding (and get lost anyway, when data is relayed via TCP-IP, or captured and stored in file, sot it is unnecessary and very bad idea to depend on the gaps during decoding). My situation is that I'm not able to connect '''Mechatromotive RCD''' display on vems '''second''' serial using aim stream * '''when it's configured old way on main serial there is no problem it just works'''. * '''I'm able to connect phone with VD app on both serial ports when ecu is configured accordingly.''' I need to know what I should write in email for mechatromotive support guys. Isn't it easier to use 1st serial port if the device cannot decode the series of 5 byte packets (bytes in the order of AIM stream) ? * '''Mechatromotive RCD''' is the first such device reported being unable to decode the series of 5 byte packets (bytes in the order of AIM stream) yes, I have connected aim dashes, racetechnology dashes, and bunch of other stuff and none of them had any problem with second serial stream. ** Mechatromotive RCD apparently prepares FW (see below) to decode regardless of gaps, very good. ---- issue why I want to use dash on second serial stream is because we need to have '''raspberry pi based datalogger connected on first serial''', we need to '''log how the gearbox is working, samsonas sequential one''', it has some problems, so we want to monitor it how it acts after some time :) ----- I will send links to mechatromotive guys from this and broadcastAIM will see are they able to sort that. ----- * got reply from mechatromotive, have new hex file which should have fix for the problem, will test on sunday or next Monday. if it goes right will upload it here. ** wow, mechatromotive seems helpful, apparently prepares FW to decode AIM regardless of gaps, good improvement, thanks. ---- uploaded hex file provided by mechatromotive guys, can confirm, it works on both serial ports now. https://drive.google.com/open?id=1LDdbB9aDzSWeJgjA2XHMAKBCIGJM2-ls
Optional: Add document to category:
Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.