Date   

locked Re: Opening/closing window wipes decodes

Jallu, OH4NDU
 

Have you tried to disable all visual and audio effects from windows desktop? That solved my similar problem with W7.

Jari
OH4NDU


locked Re: Opening/closing window wipes decodes

Lawrence Godek
 

Mine does the same thing.  I'm using XP Pro with the newest versions, whichever they are.
Larry
W0OGH

On Fri, Dec 8, 2017 at 10:05 AM, Tim Rife <lists_01@...> wrote:
Possibly off topic as I think this is a Windows thing.  But, I notice when I am listening to FT8 decodes that when I either minimize or maximize another window during the 15 second RX period, JTAlert will not display any call signs during that period.  For example, if I am looking at QRZ on my browser and minimize that window during the 15 second cycle, there will be no decodes show up in JTAlert.  Same thing if I maximize the browser window during that time period.  Anyone know why that happens?  Is there a windows setting I need to set differently?  Windows 7 64bit professional here using WSJT-X 1.8.

Thanks,

Tim
KK9T



locked Re: jtalert v2.10.5 - with WSJTX V.18 / Windows 10 ----Can not save JT Alert settings

Joe
 

It is working now. I had to delete all the files (2)
Just did config settings and pointed jt to my adif log file for rescan. Saved perfectly and B4 alerts are showing fine.

Thanks for the help and especially for a great program..

Joe
VE1BWV


On Fri, Dec 8, 2017, 1:45 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
On 9/12/2017 4:35 AM, Joe wrote:
I have used Jtalert for a long time and it has worked very well!.
I recently cloned my hd to a larger one... everything appears to be working fine with the exception of JTalert

I works but always but jtalert always returns to default settings.
If i go into JT Alert settings and assign various settings, sound card for announce , It appears ok , sounds selected , voice speaks etc 
However, as soon as i save  and close the setting they all return back to default.

I have deleted and reinstalled but no change...

Any help would be much appreciated

Joe
VE1BWV
Joe,

Sounds like your config file has become corrupt.
JTAlert maintains backups of the config.sqlite file (up to 7 days worth) so you should be able to recover by restoring one of the backups.
Do the following...
  1. Stop JTAlert
  2. Use Windows Explorer and navigate to the following directory...
    %localappdata%\HamApps\
    VE1BWV\config\JTAlertX\
  3. You will see several files with a utc data/time as part of the filename. These are the backups and the data/time was when they were created.
  4. Delete the config.sqlite file.
  5. Rename one of the backup files to config.sqlite, choose a file that was created prior to you experiencing the Settings save problem.
  6. Start JTAlert and open the Settings and make a simple change.
  7. Close the Settings and JTAlert.
  8. Start JTAlert and open the Settings and check if the change made in step 6 is still set.
  9. If the change wasn't remembered, repeat steps 4 to 8, using an older backup.
  10. If none of the backups correct the problem, then the only option is to delete the config.sqlite file and start JTAlert without that file. It will be automatically created and you will need to re-enter your Settings and run a Scan Log to update your Wanted Lists.

de Laurie VK3AMA


locked New JTAlert 2.10.6 Available - JTDX FT8 Patch. #Announcement #NewRelease

HamApps Support (VK3AMA)
 


Patched to correct the non-standard reporting of FT8 decodes by JTDX (FT8 incorrectly alerted and spotted as MSK144)

Download from HamApps.com

de Laurie VK3AMA
   


locked Re: #WARNING : JTDX FT8 decodes incorrectly alerted and spotted as MSK144 by JTAlert

Игорь Ч <c_igor@...>
 

Hello Laurie,

We have decided to come to WSJT-X standard in JTDX UDP posting of the decoded messages.

Mode designator characters are set to:

T10 mode  as   +
FT8 mode as    ~

There is built JTDX v18.1.0.31 where these changes are made and UDP posting is enabled:

https://cloud.mail.ru/public/7DV6/KVCK9W6N3 

SHA-256: 4096B96258A09DF680E79E467EDFE9675DD19DB981003C151543F98C4013DD9B

73 Igor UA3DJY


Пятница, 8 декабря 2017, 13:00 +03:00 от Игорь Ч <c_igor@...>:

Laurie,

I have blocked UDP posting of the decoded messages in JTDX v18.1.0.30 that is published for wide trial, there shall not be FT8/MSK144 spots reported from JTDX.

73 Igor UA3DJY


Пятница, 8 декабря 2017, 7:54 +03:00 от Игорь Ч via Groups.Io <c_igor@...>:

Hello Laurie,

It might be not a good idea to rely on internal software symbols to identify operation mode in UDP messages and making it as common standard, what do you think if we will replace such symbols with  the mode name in the UDP packet payload?

73 Igor UA3DJY


Пятница, 8 декабря 2017, 7:13 +03:00 от "HamApps Support (VK3AMA)" <vk3ama.ham.apps@...>:

[Edited Message Follows]

The latest release of JTDX (18.1) now supports FT8. JTAlert/JTDX users will note that these FT8 decodes are identified (alerted and spotted to HamSpots) incorrectly as MSK144.

This is caused by JTDX not fully supporting the WSJT-X UDP protocol standard. Each UDP decode has a mode identification symbol (a
single character).

JTDX identifies FT8 decodes by the "&" character which is the same character long used by WSJT-X for MSK144. This results in the wrong mode identified by JTAlert.

A new JTAlert release to workaround this will be required. Unfortunately, this new release is not likely until the New Year at the earliest.

A suggestion for the JTDX developers:
Your little used T10 mode uses the FT8 identification symbol "~". Why not make a symbol change for T10 (to stop using the FT8 symbol) and then use the correct symbol for your FT8 implementation, keeping it compatible with the WSJT-X standard. Since there are only a very small number of active T10 users, the inconvenience to JTDX users will be minimized. If you go down this path there will still need to be a new JTAlert release to remove the current T10/FT8 conflict workaround currently in-place.

de Laurie VK3AMA









--
Игорь Ч


locked Re: jtalert v2.10.5 - with WSJTX V.18 / Windows 10 ----Can not save JT Alert settings

HamApps Support (VK3AMA)
 

On 9/12/2017 4:35 AM, Joe wrote:
I have used Jtalert for a long time and it has worked very well!.
I recently cloned my hd to a larger one... everything appears to be working fine with the exception of JTalert

I works but always but jtalert always returns to default settings.
If i go into JT Alert settings and assign various settings, sound card for announce , It appears ok , sounds selected , voice speaks etc 
However, as soon as i save  and close the setting they all return back to default.

I have deleted and reinstalled but no change...

Any help would be much appreciated

Joe
VE1BWV
Joe,

Sounds like your config file has become corrupt.
JTAlert maintains backups of the config.sqlite file (up to 7 days worth) so you should be able to recover by restoring one of the backups.
Do the following...
  1. Stop JTAlert
  2. Use Windows Explorer and navigate to the following directory...
    %localappdata%\HamApps\
    VE1BWV\config\JTAlertX\
  3. You will see several files with a utc data/time as part of the filename. These are the backups and the data/time was when they were created.
  4. Delete the config.sqlite file.
  5. Rename one of the backup files to config.sqlite, choose a file that was created prior to you experiencing the Settings save problem.
  6. Start JTAlert and open the Settings and make a simple change.
  7. Close the Settings and JTAlert.
  8. Start JTAlert and open the Settings and check if the change made in step 6 is still set.
  9. If the change wasn't remembered, repeat steps 4 to 8, using an older backup.
  10. If none of the backups correct the problem, then the only option is to delete the config.sqlite file and start JTAlert without that file. It will be automatically created and you will need to re-enter your Settings and run a Scan Log to update your Wanted Lists.

de Laurie VK3AMA


locked jtalert v2.10.5 - with WSJTX V.18 / Windows 10 ----Can not save JT Alert settings

Joe
 

I have used Jtalert for a long time and it has worked very well!.
I recently cloned my hd to a larger one... everything appears to be working fine with the exception of JTalert

I works but always but jtalert always returns to default settings.
If i go into JT Alert settings and assign various settings, sound card for announce , It appears ok , sounds selected , voice speaks etc 
However, as soon as i save  and close the setting they all return back to default.

I have deleted and reinstalled but no change...

Any help would be much appreciated

Joe
VE1BWV


locked Opening/closing window wipes decodes

Tim Rife
 

Possibly off topic as I think this is a Windows thing.  But, I notice when I am listening to FT8 decodes that when I either minimize or maximize another window during the 15 second RX period, JTAlert will not display any call signs during that period.  For example, if I am looking at QRZ on my browser and minimize that window during the 15 second cycle, there will be no decodes show up in JTAlert.  Same thing if I maximize the browser window during that time period.  Anyone know why that happens?  Is there a windows setting I need to set differently?  Windows 7 64bit professional here using WSJT-X 1.8.

Thanks,

Tim
KK9T


locked Thanks for the add!!

roamer
 

Glad to join.  I hope to be able to contibute as well as learn from the experience.

73, Dean K7NO


locked Re: #WARNING : JTDX FT8 decodes incorrectly alerted and spotted as MSK144 by JTAlert

Michael Black
 

It's a single character so it uses minimum space on the decode line.  In theory having it state the actual mode name would be nice...just not practical.

de Mike W9MDB



On Thursday, December 7, 2017, 8:54:47 PM PST, Игорь Ч via Groups.Io <c_igor@...> wrote:


Hello Laurie,

It might be not a good idea to rely on internal software symbols to identify operation mode in UDP messages and making it as common standard, what do you think if we will replace such symbols with  the mode name in the UDP packet payload?

73 Igor UA3DJY


Пятница, 8 декабря 2017, 7:13 +03:00 от "HamApps Support (VK3AMA)" <vk3ama.ham.apps@...>:

[Edited Message Follows]

The latest release of JTDX (18.1) now supports FT8. JTAlert/JTDX users will note that these FT8 decodes are identified (alerted and spotted to HamSpots) incorrectly as MSK144.

This is caused by JTDX not fully supporting the WSJT-X UDP protocol standard. Each UDP decode has a mode identification symbol (a
single character).

JTDX identifies FT8 decodes by the "&" character which is the same character long used by WSJT-X for MSK144. This results in the wrong mode identified by JTAlert.

A new JTAlert release to workaround this will be required. Unfortunately, this new release is not likely until the New Year at the earliest.

A suggestion for the JTDX developers:
Your little used T10 mode uses the FT8 identification symbol "~". Why not make a symbol change for T10 (to stop using the FT8 symbol) and then use the correct symbol for your FT8 implementation, keeping it compatible with the WSJT-X standard. Since there are only a very small number of active T10 users, the inconvenience to JTDX users will be minimized. If you go down this path there will still need to be a new JTAlert release to remove the current T10/FT8 conflict workaround currently in-place.

de Laurie VK3AMA





locked Re: #WARNING : JTDX FT8 decodes incorrectly alerted and spotted as MSK144 by JTAlert

Игорь Ч <c_igor@...>
 

Laurie,

I have blocked UDP posting of the decoded messages in JTDX v18.1.0.30 that is published for wide trial, there shall not be FT8/MSK144 spots reported from JTDX.

73 Igor UA3DJY


Пятница, 8 декабря 2017, 7:54 +03:00 от Игорь Ч via Groups.Io <c_igor@...>:

Hello Laurie,

It might be not a good idea to rely on internal software symbols to identify operation mode in UDP messages and making it as common standard, what do you think if we will replace such symbols with  the mode name in the UDP packet payload?

73 Igor UA3DJY


Пятница, 8 декабря 2017, 7:13 +03:00 от "HamApps Support (VK3AMA)" <vk3ama.ham.apps@...>:

[Edited Message Follows]

The latest release of JTDX (18.1) now supports FT8. JTAlert/JTDX users will note that these FT8 decodes are identified (alerted and spotted to HamSpots) incorrectly as MSK144.

This is caused by JTDX not fully supporting the WSJT-X UDP protocol standard. Each UDP decode has a mode identification symbol (a
single character).

JTDX identifies FT8 decodes by the "&" character which is the same character long used by WSJT-X for MSK144. This results in the wrong mode identified by JTAlert.

A new JTAlert release to workaround this will be required. Unfortunately, this new release is not likely until the New Year at the earliest.

A suggestion for the JTDX developers:
Your little used T10 mode uses the FT8 identification symbol "~". Why not make a symbol change for T10 (to stop using the FT8 symbol) and then use the correct symbol for your FT8 implementation, keeping it compatible with the WSJT-X standard. Since there are only a very small number of active T10 users, the inconvenience to JTDX users will be minimized. If you go down this path there will still need to be a new JTAlert release to remove the current T10/FT8 conflict workaround currently in-place.

de Laurie VK3AMA








locked Re: Users that are successfully using this combination ACL,wsjt-x, jtalert and QRZ Logbook - I need your help please

Peter Vouvounas
 

Laurie,

The info you have shared was a tremendous help. Thank you...

Can you share some light on two other fields QSLMSG & QTH ?

I have both fields set in both jtalert & ACL check boxes and within ACL as
below.

No information is showing up in either field within ADIF exports. Use ur
direction to check & correct issues around these items

OTHER7 set to QSLMSG
OTHER8 set to QTH

Regards,

PeterV WB3FSR Jersey Shore

-----Original Message-----
From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf
Of HamApps Support (VK3AMA)
Sent: Thursday, December 07, 2017 8:58 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Users that are successfully using this combination
ACL,wsjt-x, jtalert and QRZ Logbook - I need your help please

On 7/12/2017 3:31 AM, Peter Vouvounas wrote:
'MY_GRIDSQUARE' is NOT present within the ACL adif exports now.  I
think this is a problem and we need detailed help to get this right.
Peter,

That is only something Scott N3FJP can answer. As a guess, ACL is not
exporting the MY_QRIDSQUARE data if the QSO record doesn't contain a value
for MY_GRIDSQUARE. This is typical behaviour for adif files, when there is
missing data, the corresponding adif field is not included in the adif file.
See further down for the cause (change the Other6 adif field name to
MY_GRIDSQUARE)

ACLog doesn't support the logging of MY_GRIDSQUARE and is why the JTAlert
allows logging of this data to one of the ACLog "Other" fields and if you
provide that "Other" field with the appropriate ADIF field name,
"MY_GRIDSQUARE" (this is set with ACL) that ADIF field name will be used in
the ADIF export.

OTHER6 (contains my gridsquare)

This resulted in QSL Logbook placing my grid square information in the
worked stations QRZ logbook record!
This behaviour will be due to you naming the "Other6" filed as "GRIDSQUARE",
it should be named "MY_GRIDSQUARE".

After re-examining the JTAlert code, there is a previously unreported minor
defect in the JTAlert Settings description for ACLog. The "Enable WSJT-X
gridsquare logging to this field" should say "Enable WSJT-X MY_GRIDSQUARE
logging to this field".

de Laurie VK3AMA


locked Re: #WARNING : JTDX FT8 decodes incorrectly alerted and spotted as MSK144 by JTAlert

Игорь Ч <c_igor@...>
 

Hello Laurie,

It might be not a good idea to rely on internal software symbols to identify operation mode in UDP messages and making it as common standard, what do you think if we will replace such symbols with  the mode name in the UDP packet payload?

73 Igor UA3DJY


Пятница, 8 декабря 2017, 7:13 +03:00 от "HamApps Support (VK3AMA)" <vk3ama.ham.apps@...>:

[Edited Message Follows]

The latest release of JTDX (18.1) now supports FT8. JTAlert/JTDX users will note that these FT8 decodes are identified (alerted and spotted to HamSpots) incorrectly as MSK144.

This is caused by JTDX not fully supporting the WSJT-X UDP protocol standard. Each UDP decode has a mode identification symbol (a
single character).

JTDX identifies FT8 decodes by the "&" character which is the same character long used by WSJT-X for MSK144. This results in the wrong mode identified by JTAlert.

A new JTAlert release to workaround this will be required. Unfortunately, this new release is not likely until the New Year at the earliest.

A suggestion for the JTDX developers:
Your little used T10 mode uses the FT8 identification symbol "~". Why not make a symbol change for T10 (to stop using the FT8 symbol) and then use the correct symbol for your FT8 implementation, keeping it compatible with the WSJT-X standard. Since there are only a very small number of active T10 users, the inconvenience to JTDX users will be minimized. If you go down this path there will still need to be a new JTAlert release to remove the current T10/FT8 conflict workaround currently in-place.

de Laurie VK3AMA





locked Re: Waning : JTDX FT8 decodes incorrectly alerted and spotted as MSK144 by JTAlert

Игорь Ч <c_igor@...>
 

Hello Laurie,

It might be not a good idea to rely on internal software symbols to identify operation mode in UDP messages and making it as common standard, what do you think if we will replace such symbols with  mode name in the UDP packet payload?

73 Igor UA3DJY


Пятница, 8 декабря 2017, 6:53 +03:00 от "HamApps Support (VK3AMA)" <vk3ama.ham.apps@...>:

The latest release of JTDX (18.1) now supports FT8. JTAlert/JTDX users will note that these FT8 decodes are identified (alerted and spotted to HamSpots) incorrectly as MSK144.

This is caused by JTDX not fully supporting the WSJT-X UDP protocol standard. Each UDP decode has a mode identification symbol (a
single character).

JTDX identifies FT8 decodes by the "&" character which the the same character long used by WSJT-X for MSK144 which results in the wrong mode identified by JTAlert.

A new JTAlert release to workaround this will be required. Unfortunately, this new release is not likely until the New Year at the earliest.

A suggestion for the JTDX developers:
Your little used T10 mode uses the FT8 identification symbol "~". Why not make a symbol change for T10 (to stop using the FT8 symbol) and then use the correct symbol for your FT8 implementation, keeping it compatible with the WSJT-X standard. Since there are only a very small number of active T10 users, the inconvenience to JTDX users will be minimised. If you go down this path there will still need to be a new JTAlert release to remove the current T10/FT8 conflict workaround currently in-place.

de Laurie VK3AMA





locked #WARNING : JTDX FT8 decodes incorrectly alerted and spotted as MSK144 by JTAlert

HamApps Support (VK3AMA)
 
Edited

The latest release of JTDX (18.1) now supports FT8. JTAlert/JTDX users will note that these FT8 decodes are identified (alerted and spotted to HamSpots) incorrectly as MSK144.

This is caused by JTDX not fully supporting the WSJT-X UDP protocol standard. Each UDP decode has a mode identification symbol (a
single character).

JTDX identifies FT8 decodes by the "&" character which is the same character long used by WSJT-X for MSK144. This results in the wrong mode identified by JTAlert.

A new JTAlert release to workaround this will be required. Unfortunately, this new release is not likely until the New Year at the earliest.

A suggestion for the JTDX developers:
Your little used T10 mode uses the FT8 identification symbol "~". Why not make a symbol change for T10 (to stop using the FT8 symbol) and then use the correct symbol for your FT8 implementation, keeping it compatible with the WSJT-X standard. Since there are only a very small number of active T10 users, the inconvenience to JTDX users will be minimized. If you go down this path there will still need to be a new JTAlert release to remove the current T10/FT8 conflict workaround currently in-place.

de Laurie VK3AMA


locked Re: JTAlert not alerting to wanted states/intermittently not reading states from log file #FT8

HamApps Support (VK3AMA)
 

On 7/12/2017 11:52 AM, W0ASB via Groups.Io wrote:
Laurie,
Again, I apologize for not responding sooner. I saw your message that you'll be out for the remainder of the year, that that's not problem at all.

I thought I sent the report to you, though I may have misunderstood what the report contained.

You are correct, this is a LotW file, though, I thought I was able to get it working with some of my LotW files, despite not changing any settings when downloading my LotW adi file. Is the solution to check the box that includes QSL details, when downloading the report?

Here is my ADIF file.

Barrett, W0ASB

Barret,

Your LoTW adif is the reason that the JTAlert Scan Log reports that all US States are still needed on all bands and modes. It doesn't include and State data. An example of one of the QSOs in the adif...
<APP_LoTW_OWNCALL:5>W0ASB
<STATION_CALLSIGN:5>W0ASB
<CALL:6>KB9GKG
<BAND:3>40M
<FREQ:7>7.07540
<MODE:3>FT8
<APP_LoTW_MODEGROUP:4>DATA
<QSO_DATE:8>20171022
<TIME_ON:6>141315
<QSL_RCVD:1>Y
<QSLRDATE:8>20171128
<eor>

Also, this adif uses the QSL_RCVD field name to indicate that this is an ARRL LoTW confirmed QSO. The correct adif field name is
LOTW_QSL_RCVD for LoTW. Not sure why LoTW is not obeying the ADIF standard here. That wont matter for you as you have the "Card" QSL option set for the Scan Log so JTAlert will see the QSL_RCVD data and correctly identify this a QSL confirmed record.

Fundamentally, the LoTW adif export is basically worthless if you want to use it to identify no longer needed States, DXCCs, Zones, Continents, etc. The only way to achieve that would be to import the adif into a proper logger, something like DXKeeper and then have DXKeeper fill in the missing data and perform an XML lookup for each record imported. After that is done an adif export can be done from DXKeeper and JTAlert could use that. While I referenced DXKeeper, most modern feature rich loggers can perform the same task.

What is the Logger you normally use?

de Laurie VK3AMA
   



locked Re: Frequency logging issue to HRD

HamApps Support (VK3AMA)
 

On 7/12/2017 3:45 AM, Thomas Paratore wrote:
A quick update:
I received this message from HRD this morning:

From HRD:

“I have investigated further and found some issues.

It has been confirmed that the trouble you have reported is a bug in our software. It is entered in our bug tracking system and has been assigned the tracking # 0002289

Once an issue has been identified as a bug in the HRD software and has been entered in our bug tracking system for our developers to track and resolve, this support request will be closed since no further action, by the support “

Thanks all for looking into.
Thomas,

Thanks for reporting back that this is indeed a HRD defect.

Please let us know when it gets corrected.

de Laurie VK3AMA
   


locked Re: Users that are successfully using this combination ACL,wsjt-x, jtalert and QRZ Logbook - I need your help please

HamApps Support (VK3AMA)
 

On 7/12/2017 3:31 AM, Peter Vouvounas wrote:
'MY_GRIDSQUARE' is NOT present within the ACL adif exports now.  I think this is a problem and we need detailed help to get this right.
Peter,

That is only something Scott N3FJP can answer. As a guess, ACL is not exporting the MY_QRIDSQUARE data if the QSO record doesn't contain a value for MY_GRIDSQUARE. This is typical behaviour for adif files, when there is missing data, the corresponding adif field is not included in the adif file. See further down for the cause (change the Other6 adif field name to MY_GRIDSQUARE)

ACLog doesn't support the logging of MY_GRIDSQUARE and is why the JTAlert allows logging of this data to one of the ACLog "Other" fields and if you provide that "Other" field with the appropriate ADIF field name, "MY_GRIDSQUARE" (this is set with ACL) that ADIF field name will be used in the ADIF export.

OTHER6 (contains my gridsquare)

This resulted in QSL Logbook placing my grid square information in the worked stations QRZ logbook record!
This behaviour will be due to you naming the "Other6" filed as "GRIDSQUARE", it should be named "MY_GRIDSQUARE".

After re-examining the JTAlert code, there is a previously unreported minor defect in the JTAlert Settings description for ACLog. The "Enable WSJT-X gridsquare logging to this field" should say "Enable WSJT-X MY_GRIDSQUARE logging to this field".

de Laurie VK3AMA


locked Re: JTAlert Problem

HamApps Support (VK3AMA)
 

On 6/12/2017 10:27 AM, tparty@... wrote:
ok .. was working fine one day .. load it the next day and wont save the ini file or read the UDP of WSJT-X... suggestions?

Terry
W5TMP

Terry,

What .ini file are you referring to?

Is JTAlert showing an error message, if so, what does it say?

It is not clear to me from your description what is not working.
What exactly is not working?

de Laurie VK3AMA
    


locked Re: HamSpots will be offline until 2018

HamApps Support (VK3AMA)
 

On 7/12/2017 3:01 AM, Don Hill AA5AU wrote:
I went to check it this morning and found it offline. You don't realize how much you use something 'til it's not there.

Once again, thanks Laurie for all you provide for us digital junkies. Looking forward to seeing the web interface back again in the new year.

73, Don AA5AU

Don,

When HamSpots returns, it will likely still look the same. The majority of changes taking place are behind the scenes, database restructuring, index optimisation, etc.

Being offline also has the added advantage of MSK144 users are not being overwhelmed with JTDX FT8 decodes being spotted as MSK144. JTDX doesn't fully support the WSJT-X UDP protocol standard with decodes using the "MSK144" mode identification character rather than the correct "FT8" identification character. A new JTAlert version will need to be released to workaround this.

de Laurie VK3AMA
   

19621 - 19640 of 37287