- 2,168
- 3,610
- 113
- Location
- Pepperell, Massachusetts
I believe Battery Voltage = D1 8 is really D1 B Typo?
Steel Soldiers now has a few new forums, read more about it at: New Munitions Forums!
yep was a typo i fixed it, that B1 28 corresponds to "ON" number 4 on your sheet, im gonna guess it battle short u will have to test to see if the response is a 1 with battle short onI believe Battery Voltage = D1 8 is really D1 B Typo?
if ( CParamDataModel2::GetEnumIndex((CWnd *)((char *)v112 + 212), 0x28B1u) )
v9 = "ON";
else
v9 = off_E2824C;
I'll try and test that tomorrow. I just shut my 1030 down for the night.yep was a typo i fixed it, that B1 28 corresponds to "ON" number 4 on your sheet, im gonna guess it battle short u will have to test to see if the response is a 1 with battle short on
C++:if ( CParamDataModel2::GetEnumIndex((CWnd *)((char *)v112 + 212), 0x28B1u) ) v9 = "ON"; else v9 = off_E2824C;
alsoI'll try and test that tomorrow. I just shut my 1030 down for the night.
if ( CParamDataModel2::GetEnumIndex((CWnd *)((char *)v112 + 212), 0x2C9Cu) == 2 )
{
v97 = CParamDataModel2::GetValue((int)v93, 0x104F);
v95 = v97;
v113 = 19;
ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char>>>::operator=((char *)v112 + 2012, v97);
v113 = -1;
ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char>>>::~CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char>>>(v93);
}
else
{
ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char>>>::operator=((char *)v112 + 0x7DC, "Open");
}
if ( (unsigned __int8)sub_DD1DBB("0", (char *)v112 + 2000)
|| (unsigned __int8)ATL::CSimpleStringT<char,1>::IsEmpty((char *)v112 + 0x7D0) )
{
ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char>>>::operator=(
(char *)v112 + 2028,
"Genset Configuration: ");
v85 = CParamDataModel2::GetValue((int)v81, 0x118A);
v83 = v85;
v113 = 21;
ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char>>>::operator+=((char *)v112 + 2028, v85);
v113 = -1;
ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char>>>::~CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char>>>(v81);
v79 = CParamDataModel2::GetValue((int)v69, 0x1189);
v77 = v79;
v113 = 22;
v75 = MessageBox(v71, ", ", v79);
v73 = v75;
LOBYTE(v113) = 23;
ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char>>>::operator=((char *)v112 + 2032, v75);
LOBYTE(v113) = 22;
ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char>>>::~CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char>>>(v71);
v113 = -1;
ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char>>>::~CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char>>>(v69);
v67 = CParamDataModel2::GetValue((int)v57, 0x406);
v65 = v67;
v113 = 24;
v63 = MessageBox(v59, ", ", v67);
That is awesome, now are you going to be able to write a small script that simulates this.@Icesythe7 @R1ckyb0nd
Fruitful day with the ESP32
I was able to capture ALL the handshaking between the Remote Monitor PC program and the DCS during the start of the "Connect" up to including a few blocks of 44 parameter requests and 44 DCS responses. Woot woot!
I did a couple of captures and all data back and forth was during the handshaking 100% the same.
Yea its very trivial, my library makes it pretty easyThat is awesome, now are you going to be able to write a small script that simulates this.
int main() {
bool is_connected = false;
while (!is_connected) {
std::cout << "Please choose a port number to connect." << std::endl;
int user_port;
std::cin >> user_port;
is_connected = emu.connect(static_cast<uint8_t>(user_port));
if (!is_connected) {
std::cout << "Failed to connect...please try again." << std::endl;
}
}
while (true) {
const uint8_t command = emu.read();
printf("Received command -> 0x%02X\n", command);
switch (command) {
case 0x83:
emu.handshake();
break;
case 0x86:
emu.handshake();
break;
case 0x93:
emu.respond();
break;
default:
emu.unknownCommand(command);
break;
}
}
}
bool respond() const {
std::vector<uint8_t> data;
std::vector<uint8_t> response;
const uint8_t size = read();
data.resize(size + 1);
for (int i = 0; i < size + 1; ++i) {
data[i] = read();
}
data.pop_back();
printf("Command 0x93 contains -> [%s]\n", toString(data).c_str());
//temp
if (data[0] == 0x62 && data[1] == 0x29) {
response.push_back(0x00);
return write(0x93, response);
}
if (data[0] == 0x08 && data[1] == 0x00) {
response.push_back(0x01);
response.push_back(0x06);
return write(0x93, response);
}
return write(0x93, data);
}
Can you share the capture to our gmail?@Icesythe7 @R1ckyb0nd
Fruitful day with the ESP32
I was able to capture ALL the handshaking between the Remote Monitor PC program and the DCS during the start of the "Connect" up to including a few blocks of 44 parameter requests and 44 DCS responses. Woot woot!
I did a couple of captures and all data back and forth was during the handshaking 100% the same.
I can. I just want to make double sure all the data is correct. It may be a day or so to do some sanity checking of everything I did and my code.Can you share the capture to our gmail?
Are you almost at a point where we can compile this then send the signals to the generator and display what comes backYea its very trivial, my library makes it pretty easy
I can in the software but im emulating the generator, I dont have a genset to make an emulator for the software, that side of things is up to kloppk he has a 1030 xdAre you almost at a point where we can compile this then send the signals to the generator and display what comes back
Ya something is weird in the code on initial connection, it seems it starts comms on the ui thread and then spawns a new thread just for comms and uses that from then forward, but only after it has requested data the first time...not sure if an oversight or intended but that may describe why it is doing weird stuff on initial data request.I've been looking at the various time delays between data transmissions from the PC. So far I've seen everything from 7ms to 2 seconds or so during the initial handshaking requests and parameter requests.
Weird thing I spotted. After the handshaking appears over the PC requests the 44 parameters. The responses from the DCS for the first group of 44 are what appear as longer than normal responses and appear to have lots of checksum errors. The next groups of 44 request from the PC causes the DCS to return normal values and all good checksums. Subsequent requests result in good data from the DCS.
Not sure why the first 44 requests get crap responses from the DCS.
The journey continues..
We get it, advertisements are annoying!
Sure, ad-blocking software does a great job at blocking ads, but it also blocks useful features of our website like our supporting vendors. Their ads help keep Steel Soldiers going. Please consider disabling your ad blockers for the site. Thanks!